Full_Name: Johnny Accot Version: 1.5.1 OS: Linux Submission from: (NULL) (198.4.83.52) Hi. I'm having a problem with the binary read/write functions. I'm writing a device driver in R (why not?) and of course I have to send a couple commands to the device. Typically, I send one byte, receive one acknowledgement byte, send another byte, receive an ACK, and so on. At least this is what I would like to do. Instead, after writing one byte, reading its acknowledgement byte, and writing a second byte, R hangs on the next read for an unknown reason. I guess this is a bug in the read/write functions. If you have a PS/2 device you may try to run the following code: ascii <- sapply(1:255, function(i) parse(text=paste("\"\\",structure(i,class="octmode"),"\"",sep=""))[[1]]) dev <- file("/dev/psaux") open(dev, "w+b") writeChar(ascii[246], dev, eos=NULL) readBin(dev, what=integer(), n=1, size=1, signed=FALSE) writeChar(ascii[246], dev, eos=NULL) readBin(dev, what=integer(), n=1, size=1, signed=FALSE) close(dev) which gives:> ascii <- sapply(1:255, function(i)parse(text=paste("\"\\",structure(i,class="octmode"),"\"",sep=""))[[1]])> dev <- file("/dev/psaux") > open(dev, "w+b") > writeChar(ascii[246], dev, eos=NULL) > readBin(dev, what=integer(), n=1, size=1, signed=FALSE)[1] 250> writeChar(ascii[246], dev, eos=NULL) > readBin(dev, what=integer(), n=1, size=1, signed=FALSE)[...R hangs here...] It first creates an ascii table, opens the PS/2 device for binary read&write, writes the byte 0xF6 (246 in decimal, which means: set default; it is harmless), reads the acknowledgement byte 0xFA (250 in decimal), writes another 0xF6, and then hangs when reading the second acknowledgement byte. If, instead, you close the device between the two writes, it's fine:> ascii <- sapply(1:255, function(i)parse(text=paste("\"\\",structure(i,class="octmode"),"\"",sep=""))[[1]])> > dev <- file("/dev/psaux", "w+b") > writeChar(ascii[246], dev, eos=NULL) > readBin(dev, what=integer(), n=1, size=1, signed=FALSE)[1] 250> close(dev) > > dev <- file("/dev/psaux", "w+b") > writeChar(ascii[246], dev, eos=NULL) > readBin(dev, what=integer(), n=1, size=1, signed=FALSE)[1] 250> close(dev)This is not a feature, is it? :-) The behavior is the same in versions 1.4.1, 1.5.0 and 1.5.1 on my computer. I don't have to send bytes very often, so I'll stick with the open-each-time strategy, but it is not very clean. I also tried to write bytes using the writeBin command, but it says the "size=1" is not available on my computer. This is why I'm using the writeChar function. Please let me know if I'm doing something wrong. I hope not. And thanks for the great software! :-) Johnny PS: if you try to run the code and don't get 250 as acknowledgement byte, it means the PS/2 controller is not in idle state. Very unlikely though. Try again as the set-default command should bring it back to its idle state. -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
ripley@stats.ox.ac.uk
2002-Jun-19 09:15 UTC
Maybe a problem in binary read/write (PR#1688)
Not a bug: check the documentation of file(), which is documented to work for files but not for devices. No attempt is made to cope with e.g. blocking on non-files. It's a pretty extreme view of the world to consider /dev/psaux to be a file, and R is just using standard C <stdio.h> I/O. However, this is a great opportunity for you to contribute a device() function to R. On Tue, 18 Jun 2002 accot@free.fr wrote:> Full_Name: Johnny Accot > Version: 1.5.1 > OS: Linux > Submission from: (NULL) (198.4.83.52) > > > Hi. > > I'm having a problem with the binary read/write functions. I'm writing a device > driver in R (why not?) and of course I have to send a couple commands to the > device. Typically, I send one byte, receive one acknowledgement byte, send > another byte, receive an ACK, and so on. At least this is what I would like to > do. Instead, after writing one byte, reading its acknowledgement byte, and > writing a second byte, R hangs on the next read for an unknown reason. I guess > this is a bug in the read/write functions. If you have a PS/2 device you may > try to run the following code: > > ascii <- sapply(1:255, function(i) > parse(text=paste("\"\\",structure(i,class="octmode"),"\"",sep=""))[[1]]) > dev <- file("/dev/psaux") > open(dev, "w+b") > writeChar(ascii[246], dev, eos=NULL) > readBin(dev, what=integer(), n=1, size=1, signed=FALSE) > writeChar(ascii[246], dev, eos=NULL) > readBin(dev, what=integer(), n=1, size=1, signed=FALSE) > close(dev) > > which gives: > > > ascii <- sapply(1:255, function(i) > parse(text=paste("\"\\",structure(i,class="octmode"),"\"",sep=""))[[1]]) > > dev <- file("/dev/psaux") > > open(dev, "w+b") > > writeChar(ascii[246], dev, eos=NULL) > > readBin(dev, what=integer(), n=1, size=1, signed=FALSE) > [1] 250 > > writeChar(ascii[246], dev, eos=NULL) > > readBin(dev, what=integer(), n=1, size=1, signed=FALSE) > [...R hangs here...] > > It first creates an ascii table, opens the PS/2 device for binary read&write, > writes the byte 0xF6 (246 in decimal, which means: set default; it is harmless), > reads the acknowledgement byte 0xFA (250 in decimal), writes another 0xF6, and > then hangs when reading the second acknowledgement byte. If, instead, you close > the device between the two writes, it's fine: > > > ascii <- sapply(1:255, function(i) > parse(text=paste("\"\\",structure(i,class="octmode"),"\"",sep=""))[[1]]) > > > > dev <- file("/dev/psaux", "w+b") > > writeChar(ascii[246], dev, eos=NULL) > > readBin(dev, what=integer(), n=1, size=1, signed=FALSE) > [1] 250 > > close(dev) > > > > dev <- file("/dev/psaux", "w+b") > > writeChar(ascii[246], dev, eos=NULL) > > readBin(dev, what=integer(), n=1, size=1, signed=FALSE) > [1] 250 > > close(dev) > > This is not a feature, is it? :-) The behavior is the same in versions 1.4.1, > 1.5.0 and 1.5.1 on my computer. I don't have to send bytes very often, so I'll > stick with the open-each-time strategy, but it is not very clean. > > I also tried to write bytes using the writeBin command, but it says the "size=1" > is not available on my computer. This is why I'm using the writeChar function. > > Please let me know if I'm doing something wrong. I hope not. > > And thanks for the great software! :-) > > Johnny > > PS: if you try to run the code and don't get 250 as acknowledgement byte, it > means the PS/2 controller is not in idle state. Very unlikely though. Try > again as the set-default command should bring it back to its idle state. > > -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- > r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html > Send "info", "help", or "[un]subscribe" > (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch > _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ >-- Brian D. Ripley, ripley@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Hello, Prof Brian D Ripley wrote:> Not a bug: check the documentation of file(), which is documented to work > for files but not for devices. No attempt is made to cope with e.g. > blocking on non-files. > > It's a pretty extreme view of the world to consider /dev/psaux to be a > file, and R is just using standard C <stdio.h> I/O. > > However, this is a great opportunity for you to contribute a device() > function to R.I finally checked the code and "wrote" the functions to "handle devices". Well, in fact I more or less duplicated the code for FIFOs, removed the option for encoding, added an option for synchronous I/O, and added a test to check that the file is indeed a character or block special file. This works great for me but I'm afraid it is a bit simple and does not cover much of device handling in general. Especially I don't know if anybody would want to use it for block devices, and what they would need. The psaux device is one of the simplest device one could think of, that's why it works so well. For other devices one would need at least an ioctl function, which I didn't write. But still I have no idea whether anybody would use it and what for. Anyway. Please let me know if you think this is useful. If yes, I will try to familiarize myself with the structure of the R code and make the device handling more general. Thanks, Johnny
ripley@stats.ox.ac.uk
2002-Jun-20 18:44 UTC
Maybe a problem in binary read/write (PR#1688)
On Thu, 20 Jun 2002, Johnny Accot wrote:> Hello, > > Prof Brian D Ripley wrote: > > Not a bug: check the documentation of file(), which is documented to work > > for files but not for devices. No attempt is made to cope with e.g. > > blocking on non-files. > > > > It's a pretty extreme view of the world to consider /dev/psaux to be a > > file, and R is just using standard C <stdio.h> I/O. > > > > However, this is a great opportunity for you to contribute a device() > > function to R. > > I finally checked the code and "wrote" the functions to "handle devices". > Well, in fact I more or less duplicated the code for FIFOs, removed the > option for encoding, added an option for synchronous I/O, and added a > test to check that the file is indeed a character or block special file. > This works great for me but I'm afraid it is a bit simple and does not > cover much of device handling in general. Especially I don't know if > anybody would want to use it for block devices, and what they would need. > The psaux device is one of the simplest device one could think of, that's > why it works so well. For other devices one would need at least an > ioctl function, which I didn't write. But still I have no idea whether > anybody would use it and what for. Anyway. Please let me know if you > think this is useful. If yes, I will try to familiarize myself with > the structure of the R code and make the device handling more general.Yes, I do think it would be useful, but I know little about it, Thank you for the offer.> > Thanks, > Johnny >-- Brian D. Ripley, ripley@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._