From luis.moreira at ntlworld.com Sat May 2 00:39:04 2009 From: luis.moreira at ntlworld.com (luis.moreira at ntlworld.com) Date: Sat, 2 May 2009 7:39:04 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Hi Travis, The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. The issues I still have is the errors after that. Do you have any idea what can be causing this errors? _______________________________________________________________________________ conftest.c: In function 'main': conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) conftest.c:8: error: (Each undeclared identifier is reported only once conftest.c:8: error: for each function it appears in.) conftest.c:8: error: expected ')' before string constant conftest.c:8: warning: format not a string literal and no format arguments ./configure: line 21462: ./conftest: No such file or directory ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands ------------------------------------------------------------------------------- I don't know what happened to my previous post, it as not showed up in the list. Best Regards Luis From tjarvi at qbang.org Sat May 2 07:30:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 07:30:04 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> References: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Message-ID: On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > Hi Travis, > The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. > The issues I still have is the errors after that. Do you have any idea what can be causing this errors? > > _______________________________________________________________________________ > conftest.c: In function 'main': > conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) > conftest.c:8: error: (Each undeclared identifier is reported only once > conftest.c:8: error: for each function it appears in.) > conftest.c:8: error: expected ')' before string constant > conftest.c:8: warning: format not a string literal and no format arguments > ./configure: line 21462: ./conftest: No such file or directory > ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: config.h is unchanged > config.status: executing depfiles commands > ------------------------------------------------------------------------------- > > This was corrected in CVS. I think you can just do the following in the top directory: cvs login: (pw is mousy) cvs update That will get the current fixes. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sat May 2 16:14:50 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sat, 02 May 2009 23:14:50 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FCC5DA.6000700@ntlworld.com> Trent Jarvi wrote: > > > On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > >> Hi Travis, >> The problem with the Makefile is not a problem,When I run ./configure >> I make a new Makefile with the same data in it, hence what I just >> modified is removed. >> The issues I still have is the errors after that. Do you have any >> idea what can be causing this errors? >> >> _______________________________________________________________________________ >> >> conftest.c: In function 'main': >> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >> function) >> conftest.c:8: error: (Each undeclared identifier is reported only once >> conftest.c:8: error: for each function it appears in.) >> conftest.c:8: error: expected ')' before string constant >> conftest.c:8: warning: format not a string literal and no format >> arguments >> ./configure: line 21462: ./conftest: No such file or directory >> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >> expected >> configure: creating ./config.status >> config.status: creating Makefile >> config.status: creating config.h >> config.status: config.h is unchanged >> config.status: executing depfiles commands >> ------------------------------------------------------------------------------- >> >> >> > > This was corrected in CVS. I think you can just do the following in > the top directory: > > cvs login: (pw is mousy) > cvs update > > That will get the current fixes. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, apologies for the mix-up of your name. I managed to get further on by updating CVS, the configure command gets to the end without any errors, it still warns me that it is confused about where to find the jni_md.h but I just edited the Makefile and sorted that out. I then run make, with no parameters following the instructions on the Wiki, but that generated a few more errors: ----------------------------------------------------------------------------------------------------------------------- gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. -I/usr/lib/jvm/java-6-openjdk/include /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' undeclared (first use in this function) /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared identifier is reported only once /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each function it appears in.) libtool: link: `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 ----------------------------------------------------------------------------------------------------------------------- Another question I have is, in which folder will the .so files be placed after make finishes? thank you very much for your help. Best Regards Luis From tjarvi at qbang.org Sat May 2 19:27:08 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 19:27:08 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FCC5DA.6000700@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> Message-ID: On Sat, 2 May 2009, Luis Moreira wrote: > Trent Jarvi wrote: >> >> >> On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: >> >>> Hi Travis, >>> The problem with the Makefile is not a problem,When I run ./configure >>> I make a new Makefile with the same data in it, hence what I just >>> modified is removed. >>> The issues I still have is the errors after that. Do you have any >>> idea what can be causing this errors? >>> >>> _______________________________________________________________________________ >>> >>> conftest.c: In function 'main': >>> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >>> function) >>> conftest.c:8: error: (Each undeclared identifier is reported only once >>> conftest.c:8: error: for each function it appears in.) >>> conftest.c:8: error: expected ')' before string constant >>> conftest.c:8: warning: format not a string literal and no format >>> arguments >>> ./configure: line 21462: ./conftest: No such file or directory >>> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >>> expected >>> configure: creating ./config.status >>> config.status: creating Makefile >>> config.status: creating config.h >>> config.status: config.h is unchanged >>> config.status: executing depfiles commands >>> ------------------------------------------------------------------------------- >>> >>> >>> >> >> This was corrected in CVS. I think you can just do the following in >> the top directory: >> >> cvs login: (pw is mousy) >> cvs update >> >> That will get the current fixes. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > apologies for the mix-up of your name. > I managed to get further on by updating CVS, the configure command gets > to the end without any errors, it still warns me that it is confused > about where to find the jni_md.h but I just edited the Makefile and > sorted that out. > I then run make, with no parameters following the instructions on the > Wiki, but that generated a few more errors: > ----------------------------------------------------------------------------------------------------------------------- > > gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. > -I/usr/lib/jvm/java-6-openjdk/include > /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE > -D_BSD_SOURCE -D__need_timespec -c > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o > /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' > undeclared (first use in this function) > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared > identifier is reported only once > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each > function it appears in.) > libtool: link: > `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a > valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 > ----------------------------------------------------------------------------------------------------------------------- > > Another question I have is, in which folder will the .so files be placed > after make finishes? > > thank you very much for your help. > Ah when you do cvs update pass the -Pd option cvs update -Pd Also, when you run configure, use --disable-PRINTER to only build the serial support. It will make things easier. --disable-LOCKFILES will also be easier to get going until you want to learn about how to prevent multiple applications from reading the same serial port. The link for debugging will describe where the files go. By default, it will install in the JRE/JDK under jre/lib/ext (the jar file) jre/lib/i386 (the .so file) Those are on the proper paths when you use the sun or ibm jdk. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sun May 3 01:30:43 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sun, 03 May 2009 08:30:43 +0100 Subject: [Rxtx] First use of RXTX package In-Reply-To: References: <49FCC5DA.6000700@ntlworld.com> Message-ID: <49FD4823.5080204@ntlworld.com> Ah > > when you do cvs update pass the -Pd option > > cvs update -Pd > > Also, when you run configure, use --disable-PRINTER to only build the > serial support. It will make things easier. --disable-LOCKFILES will > also be easier to get going until you want to learn about how to > prevent multiple applications from reading the same serial port. > > The link for debugging will describe where the files go. By default, > it will install in the JRE/JDK under > > jre/lib/ext (the jar file) > jre/lib/i386 (the .so file) > > Those are on the proper paths when you use the sun or ibm jdk. > > http://rxtx.qbang.org/wiki/index.php/Trouble_shooting > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, It as done it! I think this instructions you gave me should be on the Wiki, I can write them for you if you like. Also on the Wiki when you describe the three methods of installing the RxTx package it is confusing because as far as I can see, you always have to do method 1 or the .so files will not be generated(is this correct?). Then you can if you like change the location with method 1 & 2. Is it possible to modify the .la file to point to different directories for installation and then you can decide where to place the files? In a way I have learned quite a lot about Linux by having to struggle, with your help, to find solutions to the problems I encountered (I am still very new to Linux), but maybe we need to log these problems somewhere to make it less of a struggle for others like me. I have used the PortLister example to test it and it came up with my USB to dual Serial adaptor Ports. I will now explore the RxTx package, before I tackle the windows installation, I will let you know of my experience. Thank you for all your Help. Best Regards Luis From luis.moreira at ntlworld.com Sat May 2 00:39:04 2009 From: luis.moreira at ntlworld.com (luis.moreira at ntlworld.com) Date: Sat, 2 May 2009 7:39:04 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Hi Travis, The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. The issues I still have is the errors after that. Do you have any idea what can be causing this errors? _______________________________________________________________________________ conftest.c: In function 'main': conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) conftest.c:8: error: (Each undeclared identifier is reported only once conftest.c:8: error: for each function it appears in.) conftest.c:8: error: expected ')' before string constant conftest.c:8: warning: format not a string literal and no format arguments ./configure: line 21462: ./conftest: No such file or directory ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands ------------------------------------------------------------------------------- I don't know what happened to my previous post, it as not showed up in the list. Best Regards Luis From tjarvi at qbang.org Sat May 2 07:30:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 07:30:04 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> References: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Message-ID: On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > Hi Travis, > The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. > The issues I still have is the errors after that. Do you have any idea what can be causing this errors? > > _______________________________________________________________________________ > conftest.c: In function 'main': > conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) > conftest.c:8: error: (Each undeclared identifier is reported only once > conftest.c:8: error: for each function it appears in.) > conftest.c:8: error: expected ')' before string constant > conftest.c:8: warning: format not a string literal and no format arguments > ./configure: line 21462: ./conftest: No such file or directory > ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: config.h is unchanged > config.status: executing depfiles commands > ------------------------------------------------------------------------------- > > This was corrected in CVS. I think you can just do the following in the top directory: cvs login: (pw is mousy) cvs update That will get the current fixes. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sat May 2 16:14:50 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sat, 02 May 2009 23:14:50 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FCC5DA.6000700@ntlworld.com> Trent Jarvi wrote: > > > On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > >> Hi Travis, >> The problem with the Makefile is not a problem,When I run ./configure >> I make a new Makefile with the same data in it, hence what I just >> modified is removed. >> The issues I still have is the errors after that. Do you have any >> idea what can be causing this errors? >> >> _______________________________________________________________________________ >> >> conftest.c: In function 'main': >> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >> function) >> conftest.c:8: error: (Each undeclared identifier is reported only once >> conftest.c:8: error: for each function it appears in.) >> conftest.c:8: error: expected ')' before string constant >> conftest.c:8: warning: format not a string literal and no format >> arguments >> ./configure: line 21462: ./conftest: No such file or directory >> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >> expected >> configure: creating ./config.status >> config.status: creating Makefile >> config.status: creating config.h >> config.status: config.h is unchanged >> config.status: executing depfiles commands >> ------------------------------------------------------------------------------- >> >> >> > > This was corrected in CVS. I think you can just do the following in > the top directory: > > cvs login: (pw is mousy) > cvs update > > That will get the current fixes. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, apologies for the mix-up of your name. I managed to get further on by updating CVS, the configure command gets to the end without any errors, it still warns me that it is confused about where to find the jni_md.h but I just edited the Makefile and sorted that out. I then run make, with no parameters following the instructions on the Wiki, but that generated a few more errors: ----------------------------------------------------------------------------------------------------------------------- gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. -I/usr/lib/jvm/java-6-openjdk/include /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' undeclared (first use in this function) /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared identifier is reported only once /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each function it appears in.) libtool: link: `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 ----------------------------------------------------------------------------------------------------------------------- Another question I have is, in which folder will the .so files be placed after make finishes? thank you very much for your help. Best Regards Luis From tjarvi at qbang.org Sat May 2 19:27:08 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 19:27:08 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FCC5DA.6000700@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> Message-ID: On Sat, 2 May 2009, Luis Moreira wrote: > Trent Jarvi wrote: >> >> >> On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: >> >>> Hi Travis, >>> The problem with the Makefile is not a problem,When I run ./configure >>> I make a new Makefile with the same data in it, hence what I just >>> modified is removed. >>> The issues I still have is the errors after that. Do you have any >>> idea what can be causing this errors? >>> >>> _______________________________________________________________________________ >>> >>> conftest.c: In function 'main': >>> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >>> function) >>> conftest.c:8: error: (Each undeclared identifier is reported only once >>> conftest.c:8: error: for each function it appears in.) >>> conftest.c:8: error: expected ')' before string constant >>> conftest.c:8: warning: format not a string literal and no format >>> arguments >>> ./configure: line 21462: ./conftest: No such file or directory >>> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >>> expected >>> configure: creating ./config.status >>> config.status: creating Makefile >>> config.status: creating config.h >>> config.status: config.h is unchanged >>> config.status: executing depfiles commands >>> ------------------------------------------------------------------------------- >>> >>> >>> >> >> This was corrected in CVS. I think you can just do the following in >> the top directory: >> >> cvs login: (pw is mousy) >> cvs update >> >> That will get the current fixes. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > apologies for the mix-up of your name. > I managed to get further on by updating CVS, the configure command gets > to the end without any errors, it still warns me that it is confused > about where to find the jni_md.h but I just edited the Makefile and > sorted that out. > I then run make, with no parameters following the instructions on the > Wiki, but that generated a few more errors: > ----------------------------------------------------------------------------------------------------------------------- > > gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. > -I/usr/lib/jvm/java-6-openjdk/include > /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE > -D_BSD_SOURCE -D__need_timespec -c > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o > /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' > undeclared (first use in this function) > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared > identifier is reported only once > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each > function it appears in.) > libtool: link: > `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a > valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 > ----------------------------------------------------------------------------------------------------------------------- > > Another question I have is, in which folder will the .so files be placed > after make finishes? > > thank you very much for your help. > Ah when you do cvs update pass the -Pd option cvs update -Pd Also, when you run configure, use --disable-PRINTER to only build the serial support. It will make things easier. --disable-LOCKFILES will also be easier to get going until you want to learn about how to prevent multiple applications from reading the same serial port. The link for debugging will describe where the files go. By default, it will install in the JRE/JDK under jre/lib/ext (the jar file) jre/lib/i386 (the .so file) Those are on the proper paths when you use the sun or ibm jdk. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sun May 3 01:30:43 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sun, 03 May 2009 08:30:43 +0100 Subject: [Rxtx] First use of RXTX package In-Reply-To: References: <49FCC5DA.6000700@ntlworld.com> Message-ID: <49FD4823.5080204@ntlworld.com> Ah > > when you do cvs update pass the -Pd option > > cvs update -Pd > > Also, when you run configure, use --disable-PRINTER to only build the > serial support. It will make things easier. --disable-LOCKFILES will > also be easier to get going until you want to learn about how to > prevent multiple applications from reading the same serial port. > > The link for debugging will describe where the files go. By default, > it will install in the JRE/JDK under > > jre/lib/ext (the jar file) > jre/lib/i386 (the .so file) > > Those are on the proper paths when you use the sun or ibm jdk. > > http://rxtx.qbang.org/wiki/index.php/Trouble_shooting > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, It as done it! I think this instructions you gave me should be on the Wiki, I can write them for you if you like. Also on the Wiki when you describe the three methods of installing the RxTx package it is confusing because as far as I can see, you always have to do method 1 or the .so files will not be generated(is this correct?). Then you can if you like change the location with method 1 & 2. Is it possible to modify the .la file to point to different directories for installation and then you can decide where to place the files? In a way I have learned quite a lot about Linux by having to struggle, with your help, to find solutions to the problems I encountered (I am still very new to Linux), but maybe we need to log these problems somewhere to make it less of a struggle for others like me. I have used the PortLister example to test it and it came up with my USB to dual Serial adaptor Ports. I will now explore the RxTx package, before I tackle the windows installation, I will let you know of my experience. Thank you for all your Help. Best Regards Luis From tjarvi at qbang.org Sun May 3 10:37:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 3 May 2009 10:37:50 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FD4823.5080204@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> <49FD4823.5080204@ntlworld.com> Message-ID: On Sun, 3 May 2009, Luis Moreira wrote: > Ah >> >> when you do cvs update pass the -Pd option >> >> cvs update -Pd >> >> Also, when you run configure, use --disable-PRINTER to only build the >> serial support. It will make things easier. --disable-LOCKFILES will >> also be easier to get going until you want to learn about how to >> prevent multiple applications from reading the same serial port. >> >> The link for debugging will describe where the files go. By default, >> it will install in the JRE/JDK under >> >> jre/lib/ext (the jar file) >> jre/lib/i386 (the .so file) >> >> Those are on the proper paths when you use the sun or ibm jdk. >> >> http://rxtx.qbang.org/wiki/index.php/Trouble_shooting >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > It as done it! > I think this instructions you gave me should be on the Wiki, I can write > them for you if you like. Also on the Wiki when you describe the three > methods of installing the RxTx package it is confusing because as far > as I can see, you always have to do method 1 or the .so files will not > be generated(is this correct?). Then you can if you like change the > location with method 1 & 2. Is it possible to modify the .la file to > point to different directories for installation and then you can decide > where to place the files? > In a way I have learned quite a lot about Linux by having to struggle, > with your help, to find solutions to the problems I encountered (I am > still very new to Linux), but maybe we need to log these problems > somewhere to make it less of a struggle for others like me. > > I have used the PortLister example to test it and it came up with my USB > to dual Serial adaptor Ports. > > I will now explore the RxTx package, before I tackle the windows > installation, I will let you know of my experience. > > Thank you for all your Help. > Hi Luis, The locations suggested for first time configuration could be documented in a new wiki page explaining that this is not the recommended general workflow but does help new users that are not worried about having rxtx installed into the JRE. For a professional environment, the user would want to follow the workflow currently on the wiki and keep their JRE clean. Often the user will not be able to add libraries to the JRE and will need to use their home directory or a sandbox. Feel free to add information to the wiki. I'd suggest creating comment in the current page and have the comment link to what worked for you as a first time user new to Linux. You can create a new page with your comments. In the long term, we will be working on an autoinstaller that works over the web. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sat May 2 00:39:04 2009 From: luis.moreira at ntlworld.com (luis.moreira at ntlworld.com) Date: Sat, 2 May 2009 7:39:04 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Hi Travis, The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. The issues I still have is the errors after that. Do you have any idea what can be causing this errors? _______________________________________________________________________________ conftest.c: In function 'main': conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) conftest.c:8: error: (Each undeclared identifier is reported only once conftest.c:8: error: for each function it appears in.) conftest.c:8: error: expected ')' before string constant conftest.c:8: warning: format not a string literal and no format arguments ./configure: line 21462: ./conftest: No such file or directory ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands ------------------------------------------------------------------------------- I don't know what happened to my previous post, it as not showed up in the list. Best Regards Luis From tjarvi at qbang.org Sat May 2 07:30:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 07:30:04 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> References: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Message-ID: On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > Hi Travis, > The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. > The issues I still have is the errors after that. Do you have any idea what can be causing this errors? > > _______________________________________________________________________________ > conftest.c: In function 'main': > conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) > conftest.c:8: error: (Each undeclared identifier is reported only once > conftest.c:8: error: for each function it appears in.) > conftest.c:8: error: expected ')' before string constant > conftest.c:8: warning: format not a string literal and no format arguments > ./configure: line 21462: ./conftest: No such file or directory > ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: config.h is unchanged > config.status: executing depfiles commands > ------------------------------------------------------------------------------- > > This was corrected in CVS. I think you can just do the following in the top directory: cvs login: (pw is mousy) cvs update That will get the current fixes. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sat May 2 16:14:50 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sat, 02 May 2009 23:14:50 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FCC5DA.6000700@ntlworld.com> Trent Jarvi wrote: > > > On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > >> Hi Travis, >> The problem with the Makefile is not a problem,When I run ./configure >> I make a new Makefile with the same data in it, hence what I just >> modified is removed. >> The issues I still have is the errors after that. Do you have any >> idea what can be causing this errors? >> >> _______________________________________________________________________________ >> >> conftest.c: In function 'main': >> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >> function) >> conftest.c:8: error: (Each undeclared identifier is reported only once >> conftest.c:8: error: for each function it appears in.) >> conftest.c:8: error: expected ')' before string constant >> conftest.c:8: warning: format not a string literal and no format >> arguments >> ./configure: line 21462: ./conftest: No such file or directory >> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >> expected >> configure: creating ./config.status >> config.status: creating Makefile >> config.status: creating config.h >> config.status: config.h is unchanged >> config.status: executing depfiles commands >> ------------------------------------------------------------------------------- >> >> >> > > This was corrected in CVS. I think you can just do the following in > the top directory: > > cvs login: (pw is mousy) > cvs update > > That will get the current fixes. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, apologies for the mix-up of your name. I managed to get further on by updating CVS, the configure command gets to the end without any errors, it still warns me that it is confused about where to find the jni_md.h but I just edited the Makefile and sorted that out. I then run make, with no parameters following the instructions on the Wiki, but that generated a few more errors: ----------------------------------------------------------------------------------------------------------------------- gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. -I/usr/lib/jvm/java-6-openjdk/include /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' undeclared (first use in this function) /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared identifier is reported only once /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each function it appears in.) libtool: link: `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 ----------------------------------------------------------------------------------------------------------------------- Another question I have is, in which folder will the .so files be placed after make finishes? thank you very much for your help. Best Regards Luis From tjarvi at qbang.org Sat May 2 19:27:08 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 19:27:08 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FCC5DA.6000700@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> Message-ID: On Sat, 2 May 2009, Luis Moreira wrote: > Trent Jarvi wrote: >> >> >> On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: >> >>> Hi Travis, >>> The problem with the Makefile is not a problem,When I run ./configure >>> I make a new Makefile with the same data in it, hence what I just >>> modified is removed. >>> The issues I still have is the errors after that. Do you have any >>> idea what can be causing this errors? >>> >>> _______________________________________________________________________________ >>> >>> conftest.c: In function 'main': >>> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >>> function) >>> conftest.c:8: error: (Each undeclared identifier is reported only once >>> conftest.c:8: error: for each function it appears in.) >>> conftest.c:8: error: expected ')' before string constant >>> conftest.c:8: warning: format not a string literal and no format >>> arguments >>> ./configure: line 21462: ./conftest: No such file or directory >>> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >>> expected >>> configure: creating ./config.status >>> config.status: creating Makefile >>> config.status: creating config.h >>> config.status: config.h is unchanged >>> config.status: executing depfiles commands >>> ------------------------------------------------------------------------------- >>> >>> >>> >> >> This was corrected in CVS. I think you can just do the following in >> the top directory: >> >> cvs login: (pw is mousy) >> cvs update >> >> That will get the current fixes. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > apologies for the mix-up of your name. > I managed to get further on by updating CVS, the configure command gets > to the end without any errors, it still warns me that it is confused > about where to find the jni_md.h but I just edited the Makefile and > sorted that out. > I then run make, with no parameters following the instructions on the > Wiki, but that generated a few more errors: > ----------------------------------------------------------------------------------------------------------------------- > > gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. > -I/usr/lib/jvm/java-6-openjdk/include > /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE > -D_BSD_SOURCE -D__need_timespec -c > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o > /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' > undeclared (first use in this function) > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared > identifier is reported only once > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each > function it appears in.) > libtool: link: > `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a > valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 > ----------------------------------------------------------------------------------------------------------------------- > > Another question I have is, in which folder will the .so files be placed > after make finishes? > > thank you very much for your help. > Ah when you do cvs update pass the -Pd option cvs update -Pd Also, when you run configure, use --disable-PRINTER to only build the serial support. It will make things easier. --disable-LOCKFILES will also be easier to get going until you want to learn about how to prevent multiple applications from reading the same serial port. The link for debugging will describe where the files go. By default, it will install in the JRE/JDK under jre/lib/ext (the jar file) jre/lib/i386 (the .so file) Those are on the proper paths when you use the sun or ibm jdk. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sun May 3 01:30:43 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sun, 03 May 2009 08:30:43 +0100 Subject: [Rxtx] First use of RXTX package In-Reply-To: References: <49FCC5DA.6000700@ntlworld.com> Message-ID: <49FD4823.5080204@ntlworld.com> Ah > > when you do cvs update pass the -Pd option > > cvs update -Pd > > Also, when you run configure, use --disable-PRINTER to only build the > serial support. It will make things easier. --disable-LOCKFILES will > also be easier to get going until you want to learn about how to > prevent multiple applications from reading the same serial port. > > The link for debugging will describe where the files go. By default, > it will install in the JRE/JDK under > > jre/lib/ext (the jar file) > jre/lib/i386 (the .so file) > > Those are on the proper paths when you use the sun or ibm jdk. > > http://rxtx.qbang.org/wiki/index.php/Trouble_shooting > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, It as done it! I think this instructions you gave me should be on the Wiki, I can write them for you if you like. Also on the Wiki when you describe the three methods of installing the RxTx package it is confusing because as far as I can see, you always have to do method 1 or the .so files will not be generated(is this correct?). Then you can if you like change the location with method 1 & 2. Is it possible to modify the .la file to point to different directories for installation and then you can decide where to place the files? In a way I have learned quite a lot about Linux by having to struggle, with your help, to find solutions to the problems I encountered (I am still very new to Linux), but maybe we need to log these problems somewhere to make it less of a struggle for others like me. I have used the PortLister example to test it and it came up with my USB to dual Serial adaptor Ports. I will now explore the RxTx package, before I tackle the windows installation, I will let you know of my experience. Thank you for all your Help. Best Regards Luis From tjarvi at qbang.org Sun May 3 10:37:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 3 May 2009 10:37:50 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FD4823.5080204@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> <49FD4823.5080204@ntlworld.com> Message-ID: On Sun, 3 May 2009, Luis Moreira wrote: > Ah >> >> when you do cvs update pass the -Pd option >> >> cvs update -Pd >> >> Also, when you run configure, use --disable-PRINTER to only build the >> serial support. It will make things easier. --disable-LOCKFILES will >> also be easier to get going until you want to learn about how to >> prevent multiple applications from reading the same serial port. >> >> The link for debugging will describe where the files go. By default, >> it will install in the JRE/JDK under >> >> jre/lib/ext (the jar file) >> jre/lib/i386 (the .so file) >> >> Those are on the proper paths when you use the sun or ibm jdk. >> >> http://rxtx.qbang.org/wiki/index.php/Trouble_shooting >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > It as done it! > I think this instructions you gave me should be on the Wiki, I can write > them for you if you like. Also on the Wiki when you describe the three > methods of installing the RxTx package it is confusing because as far > as I can see, you always have to do method 1 or the .so files will not > be generated(is this correct?). Then you can if you like change the > location with method 1 & 2. Is it possible to modify the .la file to > point to different directories for installation and then you can decide > where to place the files? > In a way I have learned quite a lot about Linux by having to struggle, > with your help, to find solutions to the problems I encountered (I am > still very new to Linux), but maybe we need to log these problems > somewhere to make it less of a struggle for others like me. > > I have used the PortLister example to test it and it came up with my USB > to dual Serial adaptor Ports. > > I will now explore the RxTx package, before I tackle the windows > installation, I will let you know of my experience. > > Thank you for all your Help. > Hi Luis, The locations suggested for first time configuration could be documented in a new wiki page explaining that this is not the recommended general workflow but does help new users that are not worried about having rxtx installed into the JRE. For a professional environment, the user would want to follow the workflow currently on the wiki and keep their JRE clean. Often the user will not be able to add libraries to the JRE and will need to use their home directory or a sandbox. Feel free to add information to the wiki. I'd suggest creating comment in the current page and have the comment link to what worked for you as a first time user new to Linux. You can create a new page with your comments. In the long term, we will be working on an autoinstaller that works over the web. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Mon May 4 09:15:40 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Mon, 04 May 2009 16:15:40 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FF069C.8040406@ntlworld.com> Hi Trent, I have now installed the package on my 64 bit machine and when I run my program I get errors on the attachment. I know it as something to do with the architecture of my system but I can no figure out how to fix it. I have built it from source again, I did not transfer the files from machine to machine. can you please put me in the right direction. Thank you very much for your help. Best Regards Luis -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshoot.png Type: image/png Size: 25753 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090504/141ab5dc/attachment-0001.png From johnny.luong at trustcommerce.com Mon May 4 11:57:08 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 04 May 2009 10:57:08 -0700 Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FF069C.8040406@ntlworld.com> References: <49FF069C.8040406@ntlworld.com> Message-ID: <49FF2C74.90805@trustcommerce.com> Luis Moreira wrote: > Hi Trent, > I have now installed the package on my 64 bit machine and when I run my > program I get errors on the attachment. I know it as something to do > with the architecture of my system but I can no figure out how to fix > it. I have built it from source again, I did not transfer the files from > machine to machine. > can you please put me in the right direction. > Thank you very much for your help. > Best Regards > Luis > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Hi, Does running it on a 64-bit JVM help? Your host environment might be building objects for a 64-bit environment unless you did a cross-compile... -- you can find out by doing something like the following: johnny at spike:~$ java -version java version "1.6.0_0" OpenJDK Runtime Environment (build 1.6.0_0-b11) OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode) johnny at spike:~$ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) -Johnny From luis.moreira at ntlworld.com Sat May 2 00:39:04 2009 From: luis.moreira at ntlworld.com (luis.moreira at ntlworld.com) Date: Sat, 2 May 2009 7:39:04 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Hi Travis, The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. The issues I still have is the errors after that. Do you have any idea what can be causing this errors? _______________________________________________________________________________ conftest.c: In function 'main': conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) conftest.c:8: error: (Each undeclared identifier is reported only once conftest.c:8: error: for each function it appears in.) conftest.c:8: error: expected ')' before string constant conftest.c:8: warning: format not a string literal and no format arguments ./configure: line 21462: ./conftest: No such file or directory ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands ------------------------------------------------------------------------------- I don't know what happened to my previous post, it as not showed up in the list. Best Regards Luis From tjarvi at qbang.org Sat May 2 07:30:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 07:30:04 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> References: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Message-ID: On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > Hi Travis, > The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. > The issues I still have is the errors after that. Do you have any idea what can be causing this errors? > > _______________________________________________________________________________ > conftest.c: In function 'main': > conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) > conftest.c:8: error: (Each undeclared identifier is reported only once > conftest.c:8: error: for each function it appears in.) > conftest.c:8: error: expected ')' before string constant > conftest.c:8: warning: format not a string literal and no format arguments > ./configure: line 21462: ./conftest: No such file or directory > ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: config.h is unchanged > config.status: executing depfiles commands > ------------------------------------------------------------------------------- > > This was corrected in CVS. I think you can just do the following in the top directory: cvs login: (pw is mousy) cvs update That will get the current fixes. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sat May 2 16:14:50 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sat, 02 May 2009 23:14:50 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FCC5DA.6000700@ntlworld.com> Trent Jarvi wrote: > > > On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > >> Hi Travis, >> The problem with the Makefile is not a problem,When I run ./configure >> I make a new Makefile with the same data in it, hence what I just >> modified is removed. >> The issues I still have is the errors after that. Do you have any >> idea what can be causing this errors? >> >> _______________________________________________________________________________ >> >> conftest.c: In function 'main': >> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >> function) >> conftest.c:8: error: (Each undeclared identifier is reported only once >> conftest.c:8: error: for each function it appears in.) >> conftest.c:8: error: expected ')' before string constant >> conftest.c:8: warning: format not a string literal and no format >> arguments >> ./configure: line 21462: ./conftest: No such file or directory >> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >> expected >> configure: creating ./config.status >> config.status: creating Makefile >> config.status: creating config.h >> config.status: config.h is unchanged >> config.status: executing depfiles commands >> ------------------------------------------------------------------------------- >> >> >> > > This was corrected in CVS. I think you can just do the following in > the top directory: > > cvs login: (pw is mousy) > cvs update > > That will get the current fixes. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, apologies for the mix-up of your name. I managed to get further on by updating CVS, the configure command gets to the end without any errors, it still warns me that it is confused about where to find the jni_md.h but I just edited the Makefile and sorted that out. I then run make, with no parameters following the instructions on the Wiki, but that generated a few more errors: ----------------------------------------------------------------------------------------------------------------------- gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. -I/usr/lib/jvm/java-6-openjdk/include /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' undeclared (first use in this function) /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared identifier is reported only once /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each function it appears in.) libtool: link: `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 ----------------------------------------------------------------------------------------------------------------------- Another question I have is, in which folder will the .so files be placed after make finishes? thank you very much for your help. Best Regards Luis From tjarvi at qbang.org Sat May 2 19:27:08 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 19:27:08 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FCC5DA.6000700@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> Message-ID: On Sat, 2 May 2009, Luis Moreira wrote: > Trent Jarvi wrote: >> >> >> On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: >> >>> Hi Travis, >>> The problem with the Makefile is not a problem,When I run ./configure >>> I make a new Makefile with the same data in it, hence what I just >>> modified is removed. >>> The issues I still have is the errors after that. Do you have any >>> idea what can be causing this errors? >>> >>> _______________________________________________________________________________ >>> >>> conftest.c: In function 'main': >>> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >>> function) >>> conftest.c:8: error: (Each undeclared identifier is reported only once >>> conftest.c:8: error: for each function it appears in.) >>> conftest.c:8: error: expected ')' before string constant >>> conftest.c:8: warning: format not a string literal and no format >>> arguments >>> ./configure: line 21462: ./conftest: No such file or directory >>> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >>> expected >>> configure: creating ./config.status >>> config.status: creating Makefile >>> config.status: creating config.h >>> config.status: config.h is unchanged >>> config.status: executing depfiles commands >>> ------------------------------------------------------------------------------- >>> >>> >>> >> >> This was corrected in CVS. I think you can just do the following in >> the top directory: >> >> cvs login: (pw is mousy) >> cvs update >> >> That will get the current fixes. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > apologies for the mix-up of your name. > I managed to get further on by updating CVS, the configure command gets > to the end without any errors, it still warns me that it is confused > about where to find the jni_md.h but I just edited the Makefile and > sorted that out. > I then run make, with no parameters following the instructions on the > Wiki, but that generated a few more errors: > ----------------------------------------------------------------------------------------------------------------------- > > gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. > -I/usr/lib/jvm/java-6-openjdk/include > /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE > -D_BSD_SOURCE -D__need_timespec -c > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o > /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' > undeclared (first use in this function) > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared > identifier is reported only once > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each > function it appears in.) > libtool: link: > `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a > valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 > ----------------------------------------------------------------------------------------------------------------------- > > Another question I have is, in which folder will the .so files be placed > after make finishes? > > thank you very much for your help. > Ah when you do cvs update pass the -Pd option cvs update -Pd Also, when you run configure, use --disable-PRINTER to only build the serial support. It will make things easier. --disable-LOCKFILES will also be easier to get going until you want to learn about how to prevent multiple applications from reading the same serial port. The link for debugging will describe where the files go. By default, it will install in the JRE/JDK under jre/lib/ext (the jar file) jre/lib/i386 (the .so file) Those are on the proper paths when you use the sun or ibm jdk. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sun May 3 01:30:43 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sun, 03 May 2009 08:30:43 +0100 Subject: [Rxtx] First use of RXTX package In-Reply-To: References: <49FCC5DA.6000700@ntlworld.com> Message-ID: <49FD4823.5080204@ntlworld.com> Ah > > when you do cvs update pass the -Pd option > > cvs update -Pd > > Also, when you run configure, use --disable-PRINTER to only build the > serial support. It will make things easier. --disable-LOCKFILES will > also be easier to get going until you want to learn about how to > prevent multiple applications from reading the same serial port. > > The link for debugging will describe where the files go. By default, > it will install in the JRE/JDK under > > jre/lib/ext (the jar file) > jre/lib/i386 (the .so file) > > Those are on the proper paths when you use the sun or ibm jdk. > > http://rxtx.qbang.org/wiki/index.php/Trouble_shooting > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, It as done it! I think this instructions you gave me should be on the Wiki, I can write them for you if you like. Also on the Wiki when you describe the three methods of installing the RxTx package it is confusing because as far as I can see, you always have to do method 1 or the .so files will not be generated(is this correct?). Then you can if you like change the location with method 1 & 2. Is it possible to modify the .la file to point to different directories for installation and then you can decide where to place the files? In a way I have learned quite a lot about Linux by having to struggle, with your help, to find solutions to the problems I encountered (I am still very new to Linux), but maybe we need to log these problems somewhere to make it less of a struggle for others like me. I have used the PortLister example to test it and it came up with my USB to dual Serial adaptor Ports. I will now explore the RxTx package, before I tackle the windows installation, I will let you know of my experience. Thank you for all your Help. Best Regards Luis From tjarvi at qbang.org Sun May 3 10:37:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 3 May 2009 10:37:50 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FD4823.5080204@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> <49FD4823.5080204@ntlworld.com> Message-ID: On Sun, 3 May 2009, Luis Moreira wrote: > Ah >> >> when you do cvs update pass the -Pd option >> >> cvs update -Pd >> >> Also, when you run configure, use --disable-PRINTER to only build the >> serial support. It will make things easier. --disable-LOCKFILES will >> also be easier to get going until you want to learn about how to >> prevent multiple applications from reading the same serial port. >> >> The link for debugging will describe where the files go. By default, >> it will install in the JRE/JDK under >> >> jre/lib/ext (the jar file) >> jre/lib/i386 (the .so file) >> >> Those are on the proper paths when you use the sun or ibm jdk. >> >> http://rxtx.qbang.org/wiki/index.php/Trouble_shooting >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > It as done it! > I think this instructions you gave me should be on the Wiki, I can write > them for you if you like. Also on the Wiki when you describe the three > methods of installing the RxTx package it is confusing because as far > as I can see, you always have to do method 1 or the .so files will not > be generated(is this correct?). Then you can if you like change the > location with method 1 & 2. Is it possible to modify the .la file to > point to different directories for installation and then you can decide > where to place the files? > In a way I have learned quite a lot about Linux by having to struggle, > with your help, to find solutions to the problems I encountered (I am > still very new to Linux), but maybe we need to log these problems > somewhere to make it less of a struggle for others like me. > > I have used the PortLister example to test it and it came up with my USB > to dual Serial adaptor Ports. > > I will now explore the RxTx package, before I tackle the windows > installation, I will let you know of my experience. > > Thank you for all your Help. > Hi Luis, The locations suggested for first time configuration could be documented in a new wiki page explaining that this is not the recommended general workflow but does help new users that are not worried about having rxtx installed into the JRE. For a professional environment, the user would want to follow the workflow currently on the wiki and keep their JRE clean. Often the user will not be able to add libraries to the JRE and will need to use their home directory or a sandbox. Feel free to add information to the wiki. I'd suggest creating comment in the current page and have the comment link to what worked for you as a first time user new to Linux. You can create a new page with your comments. In the long term, we will be working on an autoinstaller that works over the web. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Mon May 4 09:15:40 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Mon, 04 May 2009 16:15:40 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FF069C.8040406@ntlworld.com> Hi Trent, I have now installed the package on my 64 bit machine and when I run my program I get errors on the attachment. I know it as something to do with the architecture of my system but I can no figure out how to fix it. I have built it from source again, I did not transfer the files from machine to machine. can you please put me in the right direction. Thank you very much for your help. Best Regards Luis -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshoot.png Type: image/png Size: 25753 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090504/141ab5dc/attachment-0002.png From johnny.luong at trustcommerce.com Mon May 4 11:57:08 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 04 May 2009 10:57:08 -0700 Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FF069C.8040406@ntlworld.com> References: <49FF069C.8040406@ntlworld.com> Message-ID: <49FF2C74.90805@trustcommerce.com> Luis Moreira wrote: > Hi Trent, > I have now installed the package on my 64 bit machine and when I run my > program I get errors on the attachment. I know it as something to do > with the architecture of my system but I can no figure out how to fix > it. I have built it from source again, I did not transfer the files from > machine to machine. > can you please put me in the right direction. > Thank you very much for your help. > Best Regards > Luis > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Hi, Does running it on a 64-bit JVM help? Your host environment might be building objects for a 64-bit environment unless you did a cross-compile... -- you can find out by doing something like the following: johnny at spike:~$ java -version java version "1.6.0_0" OpenJDK Runtime Environment (build 1.6.0_0-b11) OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode) johnny at spike:~$ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) -Johnny From luis.moreira at ntlworld.com Sat May 2 00:39:04 2009 From: luis.moreira at ntlworld.com (luis.moreira at ntlworld.com) Date: Sat, 2 May 2009 7:39:04 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Hi Travis, The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. The issues I still have is the errors after that. Do you have any idea what can be causing this errors? _______________________________________________________________________________ conftest.c: In function 'main': conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) conftest.c:8: error: (Each undeclared identifier is reported only once conftest.c:8: error: for each function it appears in.) conftest.c:8: error: expected ')' before string constant conftest.c:8: warning: format not a string literal and no format arguments ./configure: line 21462: ./conftest: No such file or directory ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands ------------------------------------------------------------------------------- I don't know what happened to my previous post, it as not showed up in the list. Best Regards Luis From tjarvi at qbang.org Sat May 2 07:30:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 07:30:04 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> References: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Message-ID: On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > Hi Travis, > The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. > The issues I still have is the errors after that. Do you have any idea what can be causing this errors? > > _______________________________________________________________________________ > conftest.c: In function 'main': > conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) > conftest.c:8: error: (Each undeclared identifier is reported only once > conftest.c:8: error: for each function it appears in.) > conftest.c:8: error: expected ')' before string constant > conftest.c:8: warning: format not a string literal and no format arguments > ./configure: line 21462: ./conftest: No such file or directory > ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: config.h is unchanged > config.status: executing depfiles commands > ------------------------------------------------------------------------------- > > This was corrected in CVS. I think you can just do the following in the top directory: cvs login: (pw is mousy) cvs update That will get the current fixes. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sat May 2 16:14:50 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sat, 02 May 2009 23:14:50 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FCC5DA.6000700@ntlworld.com> Trent Jarvi wrote: > > > On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > >> Hi Travis, >> The problem with the Makefile is not a problem,When I run ./configure >> I make a new Makefile with the same data in it, hence what I just >> modified is removed. >> The issues I still have is the errors after that. Do you have any >> idea what can be causing this errors? >> >> _______________________________________________________________________________ >> >> conftest.c: In function 'main': >> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >> function) >> conftest.c:8: error: (Each undeclared identifier is reported only once >> conftest.c:8: error: for each function it appears in.) >> conftest.c:8: error: expected ')' before string constant >> conftest.c:8: warning: format not a string literal and no format >> arguments >> ./configure: line 21462: ./conftest: No such file or directory >> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >> expected >> configure: creating ./config.status >> config.status: creating Makefile >> config.status: creating config.h >> config.status: config.h is unchanged >> config.status: executing depfiles commands >> ------------------------------------------------------------------------------- >> >> >> > > This was corrected in CVS. I think you can just do the following in > the top directory: > > cvs login: (pw is mousy) > cvs update > > That will get the current fixes. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, apologies for the mix-up of your name. I managed to get further on by updating CVS, the configure command gets to the end without any errors, it still warns me that it is confused about where to find the jni_md.h but I just edited the Makefile and sorted that out. I then run make, with no parameters following the instructions on the Wiki, but that generated a few more errors: ----------------------------------------------------------------------------------------------------------------------- gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. -I/usr/lib/jvm/java-6-openjdk/include /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' undeclared (first use in this function) /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared identifier is reported only once /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each function it appears in.) libtool: link: `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 ----------------------------------------------------------------------------------------------------------------------- Another question I have is, in which folder will the .so files be placed after make finishes? thank you very much for your help. Best Regards Luis From tjarvi at qbang.org Sat May 2 19:27:08 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 19:27:08 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FCC5DA.6000700@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> Message-ID: On Sat, 2 May 2009, Luis Moreira wrote: > Trent Jarvi wrote: >> >> >> On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: >> >>> Hi Travis, >>> The problem with the Makefile is not a problem,When I run ./configure >>> I make a new Makefile with the same data in it, hence what I just >>> modified is removed. >>> The issues I still have is the errors after that. Do you have any >>> idea what can be causing this errors? >>> >>> _______________________________________________________________________________ >>> >>> conftest.c: In function 'main': >>> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >>> function) >>> conftest.c:8: error: (Each undeclared identifier is reported only once >>> conftest.c:8: error: for each function it appears in.) >>> conftest.c:8: error: expected ')' before string constant >>> conftest.c:8: warning: format not a string literal and no format >>> arguments >>> ./configure: line 21462: ./conftest: No such file or directory >>> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >>> expected >>> configure: creating ./config.status >>> config.status: creating Makefile >>> config.status: creating config.h >>> config.status: config.h is unchanged >>> config.status: executing depfiles commands >>> ------------------------------------------------------------------------------- >>> >>> >>> >> >> This was corrected in CVS. I think you can just do the following in >> the top directory: >> >> cvs login: (pw is mousy) >> cvs update >> >> That will get the current fixes. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > apologies for the mix-up of your name. > I managed to get further on by updating CVS, the configure command gets > to the end without any errors, it still warns me that it is confused > about where to find the jni_md.h but I just edited the Makefile and > sorted that out. > I then run make, with no parameters following the instructions on the > Wiki, but that generated a few more errors: > ----------------------------------------------------------------------------------------------------------------------- > > gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. > -I/usr/lib/jvm/java-6-openjdk/include > /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE > -D_BSD_SOURCE -D__need_timespec -c > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o > /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' > undeclared (first use in this function) > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared > identifier is reported only once > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each > function it appears in.) > libtool: link: > `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a > valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 > ----------------------------------------------------------------------------------------------------------------------- > > Another question I have is, in which folder will the .so files be placed > after make finishes? > > thank you very much for your help. > Ah when you do cvs update pass the -Pd option cvs update -Pd Also, when you run configure, use --disable-PRINTER to only build the serial support. It will make things easier. --disable-LOCKFILES will also be easier to get going until you want to learn about how to prevent multiple applications from reading the same serial port. The link for debugging will describe where the files go. By default, it will install in the JRE/JDK under jre/lib/ext (the jar file) jre/lib/i386 (the .so file) Those are on the proper paths when you use the sun or ibm jdk. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sun May 3 01:30:43 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sun, 03 May 2009 08:30:43 +0100 Subject: [Rxtx] First use of RXTX package In-Reply-To: References: <49FCC5DA.6000700@ntlworld.com> Message-ID: <49FD4823.5080204@ntlworld.com> Ah > > when you do cvs update pass the -Pd option > > cvs update -Pd > > Also, when you run configure, use --disable-PRINTER to only build the > serial support. It will make things easier. --disable-LOCKFILES will > also be easier to get going until you want to learn about how to > prevent multiple applications from reading the same serial port. > > The link for debugging will describe where the files go. By default, > it will install in the JRE/JDK under > > jre/lib/ext (the jar file) > jre/lib/i386 (the .so file) > > Those are on the proper paths when you use the sun or ibm jdk. > > http://rxtx.qbang.org/wiki/index.php/Trouble_shooting > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, It as done it! I think this instructions you gave me should be on the Wiki, I can write them for you if you like. Also on the Wiki when you describe the three methods of installing the RxTx package it is confusing because as far as I can see, you always have to do method 1 or the .so files will not be generated(is this correct?). Then you can if you like change the location with method 1 & 2. Is it possible to modify the .la file to point to different directories for installation and then you can decide where to place the files? In a way I have learned quite a lot about Linux by having to struggle, with your help, to find solutions to the problems I encountered (I am still very new to Linux), but maybe we need to log these problems somewhere to make it less of a struggle for others like me. I have used the PortLister example to test it and it came up with my USB to dual Serial adaptor Ports. I will now explore the RxTx package, before I tackle the windows installation, I will let you know of my experience. Thank you for all your Help. Best Regards Luis From tjarvi at qbang.org Sun May 3 10:37:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 3 May 2009 10:37:50 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FD4823.5080204@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> <49FD4823.5080204@ntlworld.com> Message-ID: On Sun, 3 May 2009, Luis Moreira wrote: > Ah >> >> when you do cvs update pass the -Pd option >> >> cvs update -Pd >> >> Also, when you run configure, use --disable-PRINTER to only build the >> serial support. It will make things easier. --disable-LOCKFILES will >> also be easier to get going until you want to learn about how to >> prevent multiple applications from reading the same serial port. >> >> The link for debugging will describe where the files go. By default, >> it will install in the JRE/JDK under >> >> jre/lib/ext (the jar file) >> jre/lib/i386 (the .so file) >> >> Those are on the proper paths when you use the sun or ibm jdk. >> >> http://rxtx.qbang.org/wiki/index.php/Trouble_shooting >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > It as done it! > I think this instructions you gave me should be on the Wiki, I can write > them for you if you like. Also on the Wiki when you describe the three > methods of installing the RxTx package it is confusing because as far > as I can see, you always have to do method 1 or the .so files will not > be generated(is this correct?). Then you can if you like change the > location with method 1 & 2. Is it possible to modify the .la file to > point to different directories for installation and then you can decide > where to place the files? > In a way I have learned quite a lot about Linux by having to struggle, > with your help, to find solutions to the problems I encountered (I am > still very new to Linux), but maybe we need to log these problems > somewhere to make it less of a struggle for others like me. > > I have used the PortLister example to test it and it came up with my USB > to dual Serial adaptor Ports. > > I will now explore the RxTx package, before I tackle the windows > installation, I will let you know of my experience. > > Thank you for all your Help. > Hi Luis, The locations suggested for first time configuration could be documented in a new wiki page explaining that this is not the recommended general workflow but does help new users that are not worried about having rxtx installed into the JRE. For a professional environment, the user would want to follow the workflow currently on the wiki and keep their JRE clean. Often the user will not be able to add libraries to the JRE and will need to use their home directory or a sandbox. Feel free to add information to the wiki. I'd suggest creating comment in the current page and have the comment link to what worked for you as a first time user new to Linux. You can create a new page with your comments. In the long term, we will be working on an autoinstaller that works over the web. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Mon May 4 09:15:40 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Mon, 04 May 2009 16:15:40 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FF069C.8040406@ntlworld.com> Hi Trent, I have now installed the package on my 64 bit machine and when I run my program I get errors on the attachment. I know it as something to do with the architecture of my system but I can no figure out how to fix it. I have built it from source again, I did not transfer the files from machine to machine. can you please put me in the right direction. Thank you very much for your help. Best Regards Luis -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshoot.png Type: image/png Size: 25753 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090504/141ab5dc/attachment-0003.png From johnny.luong at trustcommerce.com Mon May 4 11:57:08 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 04 May 2009 10:57:08 -0700 Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FF069C.8040406@ntlworld.com> References: <49FF069C.8040406@ntlworld.com> Message-ID: <49FF2C74.90805@trustcommerce.com> Luis Moreira wrote: > Hi Trent, > I have now installed the package on my 64 bit machine and when I run my > program I get errors on the attachment. I know it as something to do > with the architecture of my system but I can no figure out how to fix > it. I have built it from source again, I did not transfer the files from > machine to machine. > can you please put me in the right direction. > Thank you very much for your help. > Best Regards > Luis > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Hi, Does running it on a 64-bit JVM help? Your host environment might be building objects for a 64-bit environment unless you did a cross-compile... -- you can find out by doing something like the following: johnny at spike:~$ java -version java version "1.6.0_0" OpenJDK Runtime Environment (build 1.6.0_0-b11) OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode) johnny at spike:~$ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) -Johnny From huangdongkai at gmail.com Wed May 6 11:06:06 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 01:06:06 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. Message-ID: Dear all, I recompile the rxtxSerial source code by MinGW32 and compile success. But when I run my Application which use rxtxSerial.dll to communicate with serial port, a runtime exception happened and application crash. I have no idea why it can not work, beacuse i have not change any source code of rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I have missed when compile the source code on Window NT? Here below is the output error massage. # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, tid=1360 # # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing windows-x86) # Problematic frame: # V [jvm.dll+0x1b6824] # # An error report file with more information is saved as: # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/32c1e699/attachment.html From tjarvi at qbang.org Wed May 6 20:04:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 May 2009 20:04:10 -0600 (MDT) Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: On Thu, 7 May 2009, dongkai huang wrote: > Dear all, > ????? I recompile the rxtxSerial source code by MinGW32 and compile success. > But when I run my Application which use rxtxSerial.dll to communicate with > serial port, a runtime exception happened and application crash.? I have no > idea why it can not work, beacuse i have not change any source code of > rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I > have missed when compile the source code on Window NT? Here below is the > output error massage. > # > # An unexpected error has been detected by Java Runtime Environment: > # > #? EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, > tid=1360 > # > # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing > windows-x86) > > # Problematic frame: > # V? [jvm.dll+0x1b6824] > # > # An error report file with more information is saved as: > # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log > # > # If you would like to submit a bug report, please visit: > #?? http://java.sun.com/webapps/bugreport/crash.jsp > # > > > Hi Dongkai Could you explain how you compiled rxtx with mingw? Did you run configure? Was the compiler native or a cross compiler (like compiling on Linux for Windows)? Is the crash happening when you first open the port or is it happening randomly later on? -- Trent Jarvi tjarvi at qbang.org From huangdongkai at gmail.com Wed May 6 20:48:56 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 10:48:56 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Hi Trent, I was followed the step on INSTALL file, did not run the configure, I used the Makefile.mingw32 which include on the source code package, and only change some path( jdk home path etc.). And I use the native compiler on Windows. The crash happened on I call the getPortIdentifiers() every time. On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Dear all, >> I recompile the rxtxSerial source code by MinGW32 and compile >> success. >> But when I run my Application which use rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and application crash. I have >> no >> idea why it can not work, beacuse i have not change any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing >> I >> have missed when compile the source code on Window NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is saved as: >> # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> > Hi Dongkai > > Could you explain how you compiled rxtx with mingw? Did you run configure? > Was the compiler native or a cross compiler (like compiling on Linux for > Windows)? > > Is the crash happening when you first open the port or is it happening > randomly later on? > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/733eded5/attachment.html From luis.moreira at ntlworld.com Sat May 2 00:39:04 2009 From: luis.moreira at ntlworld.com (luis.moreira at ntlworld.com) Date: Sat, 2 May 2009 7:39:04 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Hi Travis, The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. The issues I still have is the errors after that. Do you have any idea what can be causing this errors? _______________________________________________________________________________ conftest.c: In function 'main': conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) conftest.c:8: error: (Each undeclared identifier is reported only once conftest.c:8: error: for each function it appears in.) conftest.c:8: error: expected ')' before string constant conftest.c:8: warning: format not a string literal and no format arguments ./configure: line 21462: ./conftest: No such file or directory ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands ------------------------------------------------------------------------------- I don't know what happened to my previous post, it as not showed up in the list. Best Regards Luis From tjarvi at qbang.org Sat May 2 07:30:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 07:30:04 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> References: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Message-ID: On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > Hi Travis, > The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. > The issues I still have is the errors after that. Do you have any idea what can be causing this errors? > > _______________________________________________________________________________ > conftest.c: In function 'main': > conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) > conftest.c:8: error: (Each undeclared identifier is reported only once > conftest.c:8: error: for each function it appears in.) > conftest.c:8: error: expected ')' before string constant > conftest.c:8: warning: format not a string literal and no format arguments > ./configure: line 21462: ./conftest: No such file or directory > ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: config.h is unchanged > config.status: executing depfiles commands > ------------------------------------------------------------------------------- > > This was corrected in CVS. I think you can just do the following in the top directory: cvs login: (pw is mousy) cvs update That will get the current fixes. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sat May 2 16:14:50 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sat, 02 May 2009 23:14:50 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FCC5DA.6000700@ntlworld.com> Trent Jarvi wrote: > > > On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > >> Hi Travis, >> The problem with the Makefile is not a problem,When I run ./configure >> I make a new Makefile with the same data in it, hence what I just >> modified is removed. >> The issues I still have is the errors after that. Do you have any >> idea what can be causing this errors? >> >> _______________________________________________________________________________ >> >> conftest.c: In function 'main': >> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >> function) >> conftest.c:8: error: (Each undeclared identifier is reported only once >> conftest.c:8: error: for each function it appears in.) >> conftest.c:8: error: expected ')' before string constant >> conftest.c:8: warning: format not a string literal and no format >> arguments >> ./configure: line 21462: ./conftest: No such file or directory >> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >> expected >> configure: creating ./config.status >> config.status: creating Makefile >> config.status: creating config.h >> config.status: config.h is unchanged >> config.status: executing depfiles commands >> ------------------------------------------------------------------------------- >> >> >> > > This was corrected in CVS. I think you can just do the following in > the top directory: > > cvs login: (pw is mousy) > cvs update > > That will get the current fixes. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, apologies for the mix-up of your name. I managed to get further on by updating CVS, the configure command gets to the end without any errors, it still warns me that it is confused about where to find the jni_md.h but I just edited the Makefile and sorted that out. I then run make, with no parameters following the instructions on the Wiki, but that generated a few more errors: ----------------------------------------------------------------------------------------------------------------------- gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. -I/usr/lib/jvm/java-6-openjdk/include /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' undeclared (first use in this function) /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared identifier is reported only once /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each function it appears in.) libtool: link: `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 ----------------------------------------------------------------------------------------------------------------------- Another question I have is, in which folder will the .so files be placed after make finishes? thank you very much for your help. Best Regards Luis From tjarvi at qbang.org Sat May 2 19:27:08 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 19:27:08 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FCC5DA.6000700@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> Message-ID: On Sat, 2 May 2009, Luis Moreira wrote: > Trent Jarvi wrote: >> >> >> On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: >> >>> Hi Travis, >>> The problem with the Makefile is not a problem,When I run ./configure >>> I make a new Makefile with the same data in it, hence what I just >>> modified is removed. >>> The issues I still have is the errors after that. Do you have any >>> idea what can be causing this errors? >>> >>> _______________________________________________________________________________ >>> >>> conftest.c: In function 'main': >>> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >>> function) >>> conftest.c:8: error: (Each undeclared identifier is reported only once >>> conftest.c:8: error: for each function it appears in.) >>> conftest.c:8: error: expected ')' before string constant >>> conftest.c:8: warning: format not a string literal and no format >>> arguments >>> ./configure: line 21462: ./conftest: No such file or directory >>> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >>> expected >>> configure: creating ./config.status >>> config.status: creating Makefile >>> config.status: creating config.h >>> config.status: config.h is unchanged >>> config.status: executing depfiles commands >>> ------------------------------------------------------------------------------- >>> >>> >>> >> >> This was corrected in CVS. I think you can just do the following in >> the top directory: >> >> cvs login: (pw is mousy) >> cvs update >> >> That will get the current fixes. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > apologies for the mix-up of your name. > I managed to get further on by updating CVS, the configure command gets > to the end without any errors, it still warns me that it is confused > about where to find the jni_md.h but I just edited the Makefile and > sorted that out. > I then run make, with no parameters following the instructions on the > Wiki, but that generated a few more errors: > ----------------------------------------------------------------------------------------------------------------------- > > gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. > -I/usr/lib/jvm/java-6-openjdk/include > /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE > -D_BSD_SOURCE -D__need_timespec -c > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o > /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' > undeclared (first use in this function) > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared > identifier is reported only once > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each > function it appears in.) > libtool: link: > `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a > valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 > ----------------------------------------------------------------------------------------------------------------------- > > Another question I have is, in which folder will the .so files be placed > after make finishes? > > thank you very much for your help. > Ah when you do cvs update pass the -Pd option cvs update -Pd Also, when you run configure, use --disable-PRINTER to only build the serial support. It will make things easier. --disable-LOCKFILES will also be easier to get going until you want to learn about how to prevent multiple applications from reading the same serial port. The link for debugging will describe where the files go. By default, it will install in the JRE/JDK under jre/lib/ext (the jar file) jre/lib/i386 (the .so file) Those are on the proper paths when you use the sun or ibm jdk. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sun May 3 01:30:43 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sun, 03 May 2009 08:30:43 +0100 Subject: [Rxtx] First use of RXTX package In-Reply-To: References: <49FCC5DA.6000700@ntlworld.com> Message-ID: <49FD4823.5080204@ntlworld.com> Ah > > when you do cvs update pass the -Pd option > > cvs update -Pd > > Also, when you run configure, use --disable-PRINTER to only build the > serial support. It will make things easier. --disable-LOCKFILES will > also be easier to get going until you want to learn about how to > prevent multiple applications from reading the same serial port. > > The link for debugging will describe where the files go. By default, > it will install in the JRE/JDK under > > jre/lib/ext (the jar file) > jre/lib/i386 (the .so file) > > Those are on the proper paths when you use the sun or ibm jdk. > > http://rxtx.qbang.org/wiki/index.php/Trouble_shooting > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, It as done it! I think this instructions you gave me should be on the Wiki, I can write them for you if you like. Also on the Wiki when you describe the three methods of installing the RxTx package it is confusing because as far as I can see, you always have to do method 1 or the .so files will not be generated(is this correct?). Then you can if you like change the location with method 1 & 2. Is it possible to modify the .la file to point to different directories for installation and then you can decide where to place the files? In a way I have learned quite a lot about Linux by having to struggle, with your help, to find solutions to the problems I encountered (I am still very new to Linux), but maybe we need to log these problems somewhere to make it less of a struggle for others like me. I have used the PortLister example to test it and it came up with my USB to dual Serial adaptor Ports. I will now explore the RxTx package, before I tackle the windows installation, I will let you know of my experience. Thank you for all your Help. Best Regards Luis From tjarvi at qbang.org Sun May 3 10:37:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 3 May 2009 10:37:50 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FD4823.5080204@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> <49FD4823.5080204@ntlworld.com> Message-ID: On Sun, 3 May 2009, Luis Moreira wrote: > Ah >> >> when you do cvs update pass the -Pd option >> >> cvs update -Pd >> >> Also, when you run configure, use --disable-PRINTER to only build the >> serial support. It will make things easier. --disable-LOCKFILES will >> also be easier to get going until you want to learn about how to >> prevent multiple applications from reading the same serial port. >> >> The link for debugging will describe where the files go. By default, >> it will install in the JRE/JDK under >> >> jre/lib/ext (the jar file) >> jre/lib/i386 (the .so file) >> >> Those are on the proper paths when you use the sun or ibm jdk. >> >> http://rxtx.qbang.org/wiki/index.php/Trouble_shooting >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > It as done it! > I think this instructions you gave me should be on the Wiki, I can write > them for you if you like. Also on the Wiki when you describe the three > methods of installing the RxTx package it is confusing because as far > as I can see, you always have to do method 1 or the .so files will not > be generated(is this correct?). Then you can if you like change the > location with method 1 & 2. Is it possible to modify the .la file to > point to different directories for installation and then you can decide > where to place the files? > In a way I have learned quite a lot about Linux by having to struggle, > with your help, to find solutions to the problems I encountered (I am > still very new to Linux), but maybe we need to log these problems > somewhere to make it less of a struggle for others like me. > > I have used the PortLister example to test it and it came up with my USB > to dual Serial adaptor Ports. > > I will now explore the RxTx package, before I tackle the windows > installation, I will let you know of my experience. > > Thank you for all your Help. > Hi Luis, The locations suggested for first time configuration could be documented in a new wiki page explaining that this is not the recommended general workflow but does help new users that are not worried about having rxtx installed into the JRE. For a professional environment, the user would want to follow the workflow currently on the wiki and keep their JRE clean. Often the user will not be able to add libraries to the JRE and will need to use their home directory or a sandbox. Feel free to add information to the wiki. I'd suggest creating comment in the current page and have the comment link to what worked for you as a first time user new to Linux. You can create a new page with your comments. In the long term, we will be working on an autoinstaller that works over the web. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Mon May 4 09:15:40 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Mon, 04 May 2009 16:15:40 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FF069C.8040406@ntlworld.com> Hi Trent, I have now installed the package on my 64 bit machine and when I run my program I get errors on the attachment. I know it as something to do with the architecture of my system but I can no figure out how to fix it. I have built it from source again, I did not transfer the files from machine to machine. can you please put me in the right direction. Thank you very much for your help. Best Regards Luis -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshoot.png Type: image/png Size: 25753 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090504/141ab5dc/attachment-0004.png From johnny.luong at trustcommerce.com Mon May 4 11:57:08 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 04 May 2009 10:57:08 -0700 Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FF069C.8040406@ntlworld.com> References: <49FF069C.8040406@ntlworld.com> Message-ID: <49FF2C74.90805@trustcommerce.com> Luis Moreira wrote: > Hi Trent, > I have now installed the package on my 64 bit machine and when I run my > program I get errors on the attachment. I know it as something to do > with the architecture of my system but I can no figure out how to fix > it. I have built it from source again, I did not transfer the files from > machine to machine. > can you please put me in the right direction. > Thank you very much for your help. > Best Regards > Luis > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Hi, Does running it on a 64-bit JVM help? Your host environment might be building objects for a 64-bit environment unless you did a cross-compile... -- you can find out by doing something like the following: johnny at spike:~$ java -version java version "1.6.0_0" OpenJDK Runtime Environment (build 1.6.0_0-b11) OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode) johnny at spike:~$ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) -Johnny From huangdongkai at gmail.com Wed May 6 11:06:06 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 01:06:06 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. Message-ID: Dear all, I recompile the rxtxSerial source code by MinGW32 and compile success. But when I run my Application which use rxtxSerial.dll to communicate with serial port, a runtime exception happened and application crash. I have no idea why it can not work, beacuse i have not change any source code of rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I have missed when compile the source code on Window NT? Here below is the output error massage. # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, tid=1360 # # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing windows-x86) # Problematic frame: # V [jvm.dll+0x1b6824] # # An error report file with more information is saved as: # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/32c1e699/attachment-0001.html From tjarvi at qbang.org Wed May 6 20:04:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 May 2009 20:04:10 -0600 (MDT) Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: On Thu, 7 May 2009, dongkai huang wrote: > Dear all, > ????? I recompile the rxtxSerial source code by MinGW32 and compile success. > But when I run my Application which use rxtxSerial.dll to communicate with > serial port, a runtime exception happened and application crash.? I have no > idea why it can not work, beacuse i have not change any source code of > rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I > have missed when compile the source code on Window NT? Here below is the > output error massage. > # > # An unexpected error has been detected by Java Runtime Environment: > # > #? EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, > tid=1360 > # > # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing > windows-x86) > > # Problematic frame: > # V? [jvm.dll+0x1b6824] > # > # An error report file with more information is saved as: > # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log > # > # If you would like to submit a bug report, please visit: > #?? http://java.sun.com/webapps/bugreport/crash.jsp > # > > > Hi Dongkai Could you explain how you compiled rxtx with mingw? Did you run configure? Was the compiler native or a cross compiler (like compiling on Linux for Windows)? Is the crash happening when you first open the port or is it happening randomly later on? -- Trent Jarvi tjarvi at qbang.org From huangdongkai at gmail.com Wed May 6 20:48:56 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 10:48:56 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Hi Trent, I was followed the step on INSTALL file, did not run the configure, I used the Makefile.mingw32 which include on the source code package, and only change some path( jdk home path etc.). And I use the native compiler on Windows. The crash happened on I call the getPortIdentifiers() every time. On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Dear all, >> I recompile the rxtxSerial source code by MinGW32 and compile >> success. >> But when I run my Application which use rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and application crash. I have >> no >> idea why it can not work, beacuse i have not change any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing >> I >> have missed when compile the source code on Window NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is saved as: >> # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> > Hi Dongkai > > Could you explain how you compiled rxtx with mingw? Did you run configure? > Was the compiler native or a cross compiler (like compiling on Linux for > Windows)? > > Is the crash happening when you first open the port or is it happening > randomly later on? > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/733eded5/attachment-0001.html From m.j.tandy at warwick.ac.uk Thu May 7 10:39:12 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 7 May 2009 17:39:12 +0100 Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. Message-ID: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> I've encountered a bug in how XON/XOFF are handled on Windows. The symptoms were: 1. XON/XOFF from device to PC did not stop transmission. 2. XON/XOFF characters were present in data read from serial port input stream, when it was expected that they would be stripped out. 3. Investigation with SysInternals PortMon revealed the following configuration when using rxtx: 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 while HyperTerminal, which did not have the same problems as me, produced the following: 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 In other words, the problem is that, in addition to being told to use XON/XOFF flow control, the computer has to explicitly be told which characters to use for 'XON' and 'XOFF'. This part of the configuration was being missed out. I got the latest rxtx source from CVS, and identified the problem as an omission in the 'init_termios' function of 'termios.c', which configures the unix/termios 'c_cc' (control characters) data structure - but omits to configure the VSTART and VSTOP control characters. Later, the termios c_cc data structure is translated (by termios_to_DCB) into a data structure named 'DCB', which is passed to the windows serial port configuration interface. By adding two lines defining the standard XON/XOFF characters to the function init_termios, the bug is fixed. A patch doing this is attached. Thanks, Michael Tandy -------------- next part -------------- A non-text attachment was scrubbed... Name: xon-xoff.diff Type: application/octet-stream Size: 667 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/159c0dcc/attachment.obj From tjarvi at qbang.org Thu May 7 17:57:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 May 2009 17:57:28 -0600 (MDT) Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. In-Reply-To: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> References: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> Message-ID: On Thu, 7 May 2009, Michael Tandy wrote: > I've encountered a bug in how XON/XOFF are handled on Windows. > > The symptoms were: > 1. XON/XOFF from device to PC did not stop transmission. > 2. XON/XOFF characters were present in data read from serial port > input stream, when it was expected that they would be stripped out. > 3. Investigation with SysInternals PortMon revealed the following > configuration when using rxtx: > > 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 > BRK:0 EVT:a XON:0 XOFF:0 > > while HyperTerminal, which did not have the same problems as me, > produced the following: > > 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 > > In other words, the problem is that, in addition to being told to use > XON/XOFF flow control, the computer has to explicitly be told which > characters to use for 'XON' and 'XOFF'. This part of the configuration > was being missed out. > > I got the latest rxtx source from CVS, and identified the problem as > an omission in the 'init_termios' function of 'termios.c', which > configures the unix/termios 'c_cc' (control characters) data structure > - but omits to configure the VSTART and VSTOP control characters. > Later, the termios c_cc data structure is translated (by > termios_to_DCB) into a data structure named 'DCB', which is passed to > the windows serial port configuration interface. > > By adding two lines defining the standard XON/XOFF characters to the > function init_termios, the bug is fixed. A patch doing this is > attached. > Thanks Michael, Good timing. I plan on releasing rxtx-2.2 this coming Sunday. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sat May 2 00:39:04 2009 From: luis.moreira at ntlworld.com (luis.moreira at ntlworld.com) Date: Sat, 2 May 2009 7:39:04 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Hi Travis, The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. The issues I still have is the errors after that. Do you have any idea what can be causing this errors? _______________________________________________________________________________ conftest.c: In function 'main': conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) conftest.c:8: error: (Each undeclared identifier is reported only once conftest.c:8: error: for each function it appears in.) conftest.c:8: error: expected ')' before string constant conftest.c:8: warning: format not a string literal and no format arguments ./configure: line 21462: ./conftest: No such file or directory ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands ------------------------------------------------------------------------------- I don't know what happened to my previous post, it as not showed up in the list. Best Regards Luis From tjarvi at qbang.org Sat May 2 07:30:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 07:30:04 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> References: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Message-ID: On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > Hi Travis, > The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. > The issues I still have is the errors after that. Do you have any idea what can be causing this errors? > > _______________________________________________________________________________ > conftest.c: In function 'main': > conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) > conftest.c:8: error: (Each undeclared identifier is reported only once > conftest.c:8: error: for each function it appears in.) > conftest.c:8: error: expected ')' before string constant > conftest.c:8: warning: format not a string literal and no format arguments > ./configure: line 21462: ./conftest: No such file or directory > ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: config.h is unchanged > config.status: executing depfiles commands > ------------------------------------------------------------------------------- > > This was corrected in CVS. I think you can just do the following in the top directory: cvs login: (pw is mousy) cvs update That will get the current fixes. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sat May 2 16:14:50 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sat, 02 May 2009 23:14:50 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FCC5DA.6000700@ntlworld.com> Trent Jarvi wrote: > > > On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > >> Hi Travis, >> The problem with the Makefile is not a problem,When I run ./configure >> I make a new Makefile with the same data in it, hence what I just >> modified is removed. >> The issues I still have is the errors after that. Do you have any >> idea what can be causing this errors? >> >> _______________________________________________________________________________ >> >> conftest.c: In function 'main': >> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >> function) >> conftest.c:8: error: (Each undeclared identifier is reported only once >> conftest.c:8: error: for each function it appears in.) >> conftest.c:8: error: expected ')' before string constant >> conftest.c:8: warning: format not a string literal and no format >> arguments >> ./configure: line 21462: ./conftest: No such file or directory >> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >> expected >> configure: creating ./config.status >> config.status: creating Makefile >> config.status: creating config.h >> config.status: config.h is unchanged >> config.status: executing depfiles commands >> ------------------------------------------------------------------------------- >> >> >> > > This was corrected in CVS. I think you can just do the following in > the top directory: > > cvs login: (pw is mousy) > cvs update > > That will get the current fixes. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, apologies for the mix-up of your name. I managed to get further on by updating CVS, the configure command gets to the end without any errors, it still warns me that it is confused about where to find the jni_md.h but I just edited the Makefile and sorted that out. I then run make, with no parameters following the instructions on the Wiki, but that generated a few more errors: ----------------------------------------------------------------------------------------------------------------------- gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. -I/usr/lib/jvm/java-6-openjdk/include /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' undeclared (first use in this function) /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared identifier is reported only once /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each function it appears in.) libtool: link: `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 ----------------------------------------------------------------------------------------------------------------------- Another question I have is, in which folder will the .so files be placed after make finishes? thank you very much for your help. Best Regards Luis From tjarvi at qbang.org Sat May 2 19:27:08 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 19:27:08 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FCC5DA.6000700@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> Message-ID: On Sat, 2 May 2009, Luis Moreira wrote: > Trent Jarvi wrote: >> >> >> On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: >> >>> Hi Travis, >>> The problem with the Makefile is not a problem,When I run ./configure >>> I make a new Makefile with the same data in it, hence what I just >>> modified is removed. >>> The issues I still have is the errors after that. Do you have any >>> idea what can be causing this errors? >>> >>> _______________________________________________________________________________ >>> >>> conftest.c: In function 'main': >>> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >>> function) >>> conftest.c:8: error: (Each undeclared identifier is reported only once >>> conftest.c:8: error: for each function it appears in.) >>> conftest.c:8: error: expected ')' before string constant >>> conftest.c:8: warning: format not a string literal and no format >>> arguments >>> ./configure: line 21462: ./conftest: No such file or directory >>> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >>> expected >>> configure: creating ./config.status >>> config.status: creating Makefile >>> config.status: creating config.h >>> config.status: config.h is unchanged >>> config.status: executing depfiles commands >>> ------------------------------------------------------------------------------- >>> >>> >>> >> >> This was corrected in CVS. I think you can just do the following in >> the top directory: >> >> cvs login: (pw is mousy) >> cvs update >> >> That will get the current fixes. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > apologies for the mix-up of your name. > I managed to get further on by updating CVS, the configure command gets > to the end without any errors, it still warns me that it is confused > about where to find the jni_md.h but I just edited the Makefile and > sorted that out. > I then run make, with no parameters following the instructions on the > Wiki, but that generated a few more errors: > ----------------------------------------------------------------------------------------------------------------------- > > gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. > -I/usr/lib/jvm/java-6-openjdk/include > /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE > -D_BSD_SOURCE -D__need_timespec -c > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o > /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' > undeclared (first use in this function) > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared > identifier is reported only once > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each > function it appears in.) > libtool: link: > `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a > valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 > ----------------------------------------------------------------------------------------------------------------------- > > Another question I have is, in which folder will the .so files be placed > after make finishes? > > thank you very much for your help. > Ah when you do cvs update pass the -Pd option cvs update -Pd Also, when you run configure, use --disable-PRINTER to only build the serial support. It will make things easier. --disable-LOCKFILES will also be easier to get going until you want to learn about how to prevent multiple applications from reading the same serial port. The link for debugging will describe where the files go. By default, it will install in the JRE/JDK under jre/lib/ext (the jar file) jre/lib/i386 (the .so file) Those are on the proper paths when you use the sun or ibm jdk. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sun May 3 01:30:43 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sun, 03 May 2009 08:30:43 +0100 Subject: [Rxtx] First use of RXTX package In-Reply-To: References: <49FCC5DA.6000700@ntlworld.com> Message-ID: <49FD4823.5080204@ntlworld.com> Ah > > when you do cvs update pass the -Pd option > > cvs update -Pd > > Also, when you run configure, use --disable-PRINTER to only build the > serial support. It will make things easier. --disable-LOCKFILES will > also be easier to get going until you want to learn about how to > prevent multiple applications from reading the same serial port. > > The link for debugging will describe where the files go. By default, > it will install in the JRE/JDK under > > jre/lib/ext (the jar file) > jre/lib/i386 (the .so file) > > Those are on the proper paths when you use the sun or ibm jdk. > > http://rxtx.qbang.org/wiki/index.php/Trouble_shooting > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, It as done it! I think this instructions you gave me should be on the Wiki, I can write them for you if you like. Also on the Wiki when you describe the three methods of installing the RxTx package it is confusing because as far as I can see, you always have to do method 1 or the .so files will not be generated(is this correct?). Then you can if you like change the location with method 1 & 2. Is it possible to modify the .la file to point to different directories for installation and then you can decide where to place the files? In a way I have learned quite a lot about Linux by having to struggle, with your help, to find solutions to the problems I encountered (I am still very new to Linux), but maybe we need to log these problems somewhere to make it less of a struggle for others like me. I have used the PortLister example to test it and it came up with my USB to dual Serial adaptor Ports. I will now explore the RxTx package, before I tackle the windows installation, I will let you know of my experience. Thank you for all your Help. Best Regards Luis From tjarvi at qbang.org Sun May 3 10:37:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 3 May 2009 10:37:50 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FD4823.5080204@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> <49FD4823.5080204@ntlworld.com> Message-ID: On Sun, 3 May 2009, Luis Moreira wrote: > Ah >> >> when you do cvs update pass the -Pd option >> >> cvs update -Pd >> >> Also, when you run configure, use --disable-PRINTER to only build the >> serial support. It will make things easier. --disable-LOCKFILES will >> also be easier to get going until you want to learn about how to >> prevent multiple applications from reading the same serial port. >> >> The link for debugging will describe where the files go. By default, >> it will install in the JRE/JDK under >> >> jre/lib/ext (the jar file) >> jre/lib/i386 (the .so file) >> >> Those are on the proper paths when you use the sun or ibm jdk. >> >> http://rxtx.qbang.org/wiki/index.php/Trouble_shooting >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > It as done it! > I think this instructions you gave me should be on the Wiki, I can write > them for you if you like. Also on the Wiki when you describe the three > methods of installing the RxTx package it is confusing because as far > as I can see, you always have to do method 1 or the .so files will not > be generated(is this correct?). Then you can if you like change the > location with method 1 & 2. Is it possible to modify the .la file to > point to different directories for installation and then you can decide > where to place the files? > In a way I have learned quite a lot about Linux by having to struggle, > with your help, to find solutions to the problems I encountered (I am > still very new to Linux), but maybe we need to log these problems > somewhere to make it less of a struggle for others like me. > > I have used the PortLister example to test it and it came up with my USB > to dual Serial adaptor Ports. > > I will now explore the RxTx package, before I tackle the windows > installation, I will let you know of my experience. > > Thank you for all your Help. > Hi Luis, The locations suggested for first time configuration could be documented in a new wiki page explaining that this is not the recommended general workflow but does help new users that are not worried about having rxtx installed into the JRE. For a professional environment, the user would want to follow the workflow currently on the wiki and keep their JRE clean. Often the user will not be able to add libraries to the JRE and will need to use their home directory or a sandbox. Feel free to add information to the wiki. I'd suggest creating comment in the current page and have the comment link to what worked for you as a first time user new to Linux. You can create a new page with your comments. In the long term, we will be working on an autoinstaller that works over the web. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Mon May 4 09:15:40 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Mon, 04 May 2009 16:15:40 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FF069C.8040406@ntlworld.com> Hi Trent, I have now installed the package on my 64 bit machine and when I run my program I get errors on the attachment. I know it as something to do with the architecture of my system but I can no figure out how to fix it. I have built it from source again, I did not transfer the files from machine to machine. can you please put me in the right direction. Thank you very much for your help. Best Regards Luis -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshoot.png Type: image/png Size: 25753 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090504/141ab5dc/attachment-0005.png From johnny.luong at trustcommerce.com Mon May 4 11:57:08 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 04 May 2009 10:57:08 -0700 Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FF069C.8040406@ntlworld.com> References: <49FF069C.8040406@ntlworld.com> Message-ID: <49FF2C74.90805@trustcommerce.com> Luis Moreira wrote: > Hi Trent, > I have now installed the package on my 64 bit machine and when I run my > program I get errors on the attachment. I know it as something to do > with the architecture of my system but I can no figure out how to fix > it. I have built it from source again, I did not transfer the files from > machine to machine. > can you please put me in the right direction. > Thank you very much for your help. > Best Regards > Luis > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Hi, Does running it on a 64-bit JVM help? Your host environment might be building objects for a 64-bit environment unless you did a cross-compile... -- you can find out by doing something like the following: johnny at spike:~$ java -version java version "1.6.0_0" OpenJDK Runtime Environment (build 1.6.0_0-b11) OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode) johnny at spike:~$ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) -Johnny From huangdongkai at gmail.com Wed May 6 11:06:06 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 01:06:06 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. Message-ID: Dear all, I recompile the rxtxSerial source code by MinGW32 and compile success. But when I run my Application which use rxtxSerial.dll to communicate with serial port, a runtime exception happened and application crash. I have no idea why it can not work, beacuse i have not change any source code of rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I have missed when compile the source code on Window NT? Here below is the output error massage. # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, tid=1360 # # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing windows-x86) # Problematic frame: # V [jvm.dll+0x1b6824] # # An error report file with more information is saved as: # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/32c1e699/attachment-0002.html From tjarvi at qbang.org Wed May 6 20:04:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 May 2009 20:04:10 -0600 (MDT) Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: On Thu, 7 May 2009, dongkai huang wrote: > Dear all, > ????? I recompile the rxtxSerial source code by MinGW32 and compile success. > But when I run my Application which use rxtxSerial.dll to communicate with > serial port, a runtime exception happened and application crash.? I have no > idea why it can not work, beacuse i have not change any source code of > rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I > have missed when compile the source code on Window NT? Here below is the > output error massage. > # > # An unexpected error has been detected by Java Runtime Environment: > # > #? EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, > tid=1360 > # > # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing > windows-x86) > > # Problematic frame: > # V? [jvm.dll+0x1b6824] > # > # An error report file with more information is saved as: > # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log > # > # If you would like to submit a bug report, please visit: > #?? http://java.sun.com/webapps/bugreport/crash.jsp > # > > > Hi Dongkai Could you explain how you compiled rxtx with mingw? Did you run configure? Was the compiler native or a cross compiler (like compiling on Linux for Windows)? Is the crash happening when you first open the port or is it happening randomly later on? -- Trent Jarvi tjarvi at qbang.org From huangdongkai at gmail.com Wed May 6 20:48:56 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 10:48:56 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Hi Trent, I was followed the step on INSTALL file, did not run the configure, I used the Makefile.mingw32 which include on the source code package, and only change some path( jdk home path etc.). And I use the native compiler on Windows. The crash happened on I call the getPortIdentifiers() every time. On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Dear all, >> I recompile the rxtxSerial source code by MinGW32 and compile >> success. >> But when I run my Application which use rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and application crash. I have >> no >> idea why it can not work, beacuse i have not change any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing >> I >> have missed when compile the source code on Window NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is saved as: >> # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> > Hi Dongkai > > Could you explain how you compiled rxtx with mingw? Did you run configure? > Was the compiler native or a cross compiler (like compiling on Linux for > Windows)? > > Is the crash happening when you first open the port or is it happening > randomly later on? > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/733eded5/attachment-0002.html From m.j.tandy at warwick.ac.uk Thu May 7 10:39:12 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 7 May 2009 17:39:12 +0100 Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. Message-ID: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> I've encountered a bug in how XON/XOFF are handled on Windows. The symptoms were: 1. XON/XOFF from device to PC did not stop transmission. 2. XON/XOFF characters were present in data read from serial port input stream, when it was expected that they would be stripped out. 3. Investigation with SysInternals PortMon revealed the following configuration when using rxtx: 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 while HyperTerminal, which did not have the same problems as me, produced the following: 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 In other words, the problem is that, in addition to being told to use XON/XOFF flow control, the computer has to explicitly be told which characters to use for 'XON' and 'XOFF'. This part of the configuration was being missed out. I got the latest rxtx source from CVS, and identified the problem as an omission in the 'init_termios' function of 'termios.c', which configures the unix/termios 'c_cc' (control characters) data structure - but omits to configure the VSTART and VSTOP control characters. Later, the termios c_cc data structure is translated (by termios_to_DCB) into a data structure named 'DCB', which is passed to the windows serial port configuration interface. By adding two lines defining the standard XON/XOFF characters to the function init_termios, the bug is fixed. A patch doing this is attached. Thanks, Michael Tandy -------------- next part -------------- A non-text attachment was scrubbed... Name: xon-xoff.diff Type: application/octet-stream Size: 667 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/159c0dcc/attachment-0001.obj From tjarvi at qbang.org Thu May 7 17:57:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 May 2009 17:57:28 -0600 (MDT) Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. In-Reply-To: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> References: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> Message-ID: On Thu, 7 May 2009, Michael Tandy wrote: > I've encountered a bug in how XON/XOFF are handled on Windows. > > The symptoms were: > 1. XON/XOFF from device to PC did not stop transmission. > 2. XON/XOFF characters were present in data read from serial port > input stream, when it was expected that they would be stripped out. > 3. Investigation with SysInternals PortMon revealed the following > configuration when using rxtx: > > 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 > BRK:0 EVT:a XON:0 XOFF:0 > > while HyperTerminal, which did not have the same problems as me, > produced the following: > > 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 > > In other words, the problem is that, in addition to being told to use > XON/XOFF flow control, the computer has to explicitly be told which > characters to use for 'XON' and 'XOFF'. This part of the configuration > was being missed out. > > I got the latest rxtx source from CVS, and identified the problem as > an omission in the 'init_termios' function of 'termios.c', which > configures the unix/termios 'c_cc' (control characters) data structure > - but omits to configure the VSTART and VSTOP control characters. > Later, the termios c_cc data structure is translated (by > termios_to_DCB) into a data structure named 'DCB', which is passed to > the windows serial port configuration interface. > > By adding two lines defining the standard XON/XOFF characters to the > function init_termios, the bug is fixed. A patch doing this is > attached. > Thanks Michael, Good timing. I plan on releasing rxtx-2.2 this coming Sunday. -- Trent Jarvi tjarvi at qbang.org From wjr at weru.ksu.edu Fri May 8 11:38:29 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Fri, 08 May 2009 12:38:29 -0500 Subject: [Rxtx] swing jfilechooser lockup Message-ID: <4A046E15.6010907@weru.ksu.edu> Hi, I wrote a small swing app to download images from an industrial camera. I used the two way serial sample code as a starting point. The app works fine EXCEPT for a call to jfilechooser. After I open the comm port and then try to change the output directory or log file, the jfilechooser winds up trying to unpark (note, parking is not something I'm really familiar with) and doesn't. If I try to change the file or directory before I start the comm port, it works. If I click on menu items that don't call jfilechooser, everything is OK. If I try closing the comm port and then try to create a jfilechooser, it locks up. There is obviously some sort of deadlock here because the awt thread starts waiting on something but it's not clear what. I haven't gone thru the rxtx code yet because it's not in the file structure that netbeans wants for debugging purposes. However, debugging code that I don't have a clear idea of what it is supposed to do is not my idea of a good time. Does anyone have any ideas on what is going on here? Thanks, wjr From Bob_Jacobsen at lbl.gov Fri May 8 14:48:25 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Fri, 8 May 2009 13:48:25 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A046E15.6010907@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> Message-ID: At 12:38 PM -0500 5/8/09, Bill Rust wrote: >Hi, > >I wrote a small swing app to download images from an industrial camera. >I used the two way serial sample code as a starting point. The app works >fine EXCEPT for a call to jfilechooser. After I open the comm port and >then try to change the output directory or log file, the jfilechooser >winds up trying to unpark (note, parking is not something I'm really >familiar with) and doesn't. If I try to change the file or directory >before I start the comm port, it works. If I click on menu items that >don't call jfilechooser, everything is OK. If I try closing the comm >port and then try to create a jfilechooser, it locks up. There is >obviously some sort of deadlock here because the awt thread starts >waiting on something but it's not clear what. I haven't gone thru the >rxtx code yet because it's not in the file structure that netbeans wants >for debugging purposes. However, debugging code that I don't have a >clear idea of what it is supposed to do is not my idea of a good time. What is the threading structure of your code? The various high-function Swing components, such as JFileChooser, are notorious for doing Really Bad Stuff when invoked from off the Swing thread. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From bschlining at gmail.com Fri May 8 15:08:50 2009 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 8 May 2009 14:08:50 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: Bob's probably right...take look at javax.swing.SwingUtilites for the workaround to get your swing stuff invoked on the EventDispatchThread (EDT). Some swing-methods do work when called outside of the EDT, but just to be safe, do your creation and swing calls on the EDT. It's really simple, here's an example of a synchronous call. // Here's how to run stuff on the EDT from a different thread SwingUtilities.invokeAndWait(new Runnable() { public void run() { JFileChooser fc; // create, setup, show your filechooser // Get the result from the filechooser } }); To do a asynchronous call use SwingUtilities.invokeLater > >I wrote a small swing app to download images from an industrial camera. > >I used the two way serial sample code as a starting point. The app works > >fine EXCEPT for a call to jfilechooser. After I open the comm port and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090508/c21c2127/attachment-0001.html From tod at todbot.com Fri May 8 16:27:12 2009 From: tod at todbot.com (Tod E. Kurt) Date: Fri, 8 May 2009 15:27:12 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> This is the exact technique I use to let the user choose which serial port to use on startup. Here's a method I've got in many of my sketches: void choosePort() { String portlist[] = Serial.list(); String port = null; javax.swing.SwingUtilities.invokeLater(new Runnable() { public void run() { try { String port = (String) javax.swing.JOptionPane.showInputDialog( null, "Select Serial Port", "MySuperSketch", javax.swing.JOptionPane.QUESTION_MESSAGE, null, portlist, null); if( port == null ) { javax.swing.JOptionPane.showMessageDialog(null, "No port chosen, goodbye"); System.exit(1); } serialPort = port; } catch (Exception e) { e.printStackTrace(); } } } ); } On May 8, 2009, at 2:08 p, Brian Schlining wrote: > Bob's probably right...take look at javax.swing.SwingUtilites for > the workaround to get your swing stuff invoked on the > EventDispatchThread (EDT). Some swing-methods do work when called > outside of the EDT, but just to be safe, do your creation and swing > calls on the EDT. It's really simple, here's an example of a > synchronous call. > > // Here's how to run stuff on the EDT from a different thread > SwingUtilities.invokeAndWait(new Runnable() { > public void run() { > JFileChooser fc; // create, setup, show your filechooser > // Get the result from the filechooser > } > }); > > To do a asynchronous call use SwingUtilities.invokeLater > > > >I wrote a small swing app to download images from an industrial > camera. > >I used the two way serial sample code as a starting point. The app > works > >fine EXCEPT for a call to jfilechooser. After I open the comm port > and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From huangdongkai at gmail.com Sat May 9 04:46:22 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Sat, 9 May 2009 18:46:22 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Dear Trent, After I intsall the ming32-cross compile to compile the rxtxSerial.dll and testing, i found the same problem still exist. I am not sure my compiler version is the same as your's. Could you tell me the way you can success compile rxtx-2.1-7r2 release source code? Thanks for you kindly help. On Fri, May 8, 2009 at 8:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Hi Trent, >> The attach is the Make file I use to compile the rxtx. >> >> On Thu, May 7, 2009 at 10:48 AM, dongkai huang >> wrote: >> Hi Trent, >> I was followed the step on INSTALL file, did not run the >> configure, I used the Makefile.mingw32 which include on the >> source code package, and only change some path( jdk home path >> etc.). And I use the native compiler on Windows. >> The crash happened on I call the getPortIdentifiers() >> every time. >> >> On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: >> >> >> On Thu, 7 May 2009, dongkai huang wrote: >> >> Dear all, >> I recompile the rxtxSerial source code by >> MinGW32 and compile success. >> But when I run my Application which use >> rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and >> application crash. I have no >> idea why it can not work, beacuse i have not change >> any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source >> code. Did some thing I >> have missed when compile the source code on Window >> NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java >> Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at >> pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 >> mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is >> saved as: >> # >> D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please >> visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> >> Hi Dongkai >> >> Could you explain how you compiled rxtx with mingw? Did you run >> configure? Was the compiler native or a cross compiler (like >> compiling on Linux for Windows)? >> >> Is the crash happening when you first open the port or is it >> happening randomly later on? >> >> > Thanks Dongkai > > I'll look at your Makefile tomorrow. Which version of mingw was this? > > I suspect there is a problem with that makefile. I usually built that > version of rxtx for windows with a mingw32 cross compiler using the > configure script. > > The configure script may well work for you if you have a cygwin environment > with mingw instead of gcc. I'll take a look at what is different. > > -- > > Trent Jarvi > tjarvi at qbang.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090509/b729c429/attachment.html From luis.moreira at ntlworld.com Sat May 2 00:39:04 2009 From: luis.moreira at ntlworld.com (luis.moreira at ntlworld.com) Date: Sat, 2 May 2009 7:39:04 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Hi Travis, The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. The issues I still have is the errors after that. Do you have any idea what can be causing this errors? _______________________________________________________________________________ conftest.c: In function 'main': conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) conftest.c:8: error: (Each undeclared identifier is reported only once conftest.c:8: error: for each function it appears in.) conftest.c:8: error: expected ')' before string constant conftest.c:8: warning: format not a string literal and no format arguments ./configure: line 21462: ./conftest: No such file or directory ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands ------------------------------------------------------------------------------- I don't know what happened to my previous post, it as not showed up in the list. Best Regards Luis From tjarvi at qbang.org Sat May 2 07:30:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 07:30:04 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> References: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Message-ID: On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > Hi Travis, > The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. > The issues I still have is the errors after that. Do you have any idea what can be causing this errors? > > _______________________________________________________________________________ > conftest.c: In function 'main': > conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) > conftest.c:8: error: (Each undeclared identifier is reported only once > conftest.c:8: error: for each function it appears in.) > conftest.c:8: error: expected ')' before string constant > conftest.c:8: warning: format not a string literal and no format arguments > ./configure: line 21462: ./conftest: No such file or directory > ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: config.h is unchanged > config.status: executing depfiles commands > ------------------------------------------------------------------------------- > > This was corrected in CVS. I think you can just do the following in the top directory: cvs login: (pw is mousy) cvs update That will get the current fixes. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sat May 2 16:14:50 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sat, 02 May 2009 23:14:50 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FCC5DA.6000700@ntlworld.com> Trent Jarvi wrote: > > > On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > >> Hi Travis, >> The problem with the Makefile is not a problem,When I run ./configure >> I make a new Makefile with the same data in it, hence what I just >> modified is removed. >> The issues I still have is the errors after that. Do you have any >> idea what can be causing this errors? >> >> _______________________________________________________________________________ >> >> conftest.c: In function 'main': >> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >> function) >> conftest.c:8: error: (Each undeclared identifier is reported only once >> conftest.c:8: error: for each function it appears in.) >> conftest.c:8: error: expected ')' before string constant >> conftest.c:8: warning: format not a string literal and no format >> arguments >> ./configure: line 21462: ./conftest: No such file or directory >> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >> expected >> configure: creating ./config.status >> config.status: creating Makefile >> config.status: creating config.h >> config.status: config.h is unchanged >> config.status: executing depfiles commands >> ------------------------------------------------------------------------------- >> >> >> > > This was corrected in CVS. I think you can just do the following in > the top directory: > > cvs login: (pw is mousy) > cvs update > > That will get the current fixes. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, apologies for the mix-up of your name. I managed to get further on by updating CVS, the configure command gets to the end without any errors, it still warns me that it is confused about where to find the jni_md.h but I just edited the Makefile and sorted that out. I then run make, with no parameters following the instructions on the Wiki, but that generated a few more errors: ----------------------------------------------------------------------------------------------------------------------- gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. -I/usr/lib/jvm/java-6-openjdk/include /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' undeclared (first use in this function) /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared identifier is reported only once /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each function it appears in.) libtool: link: `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 ----------------------------------------------------------------------------------------------------------------------- Another question I have is, in which folder will the .so files be placed after make finishes? thank you very much for your help. Best Regards Luis From tjarvi at qbang.org Sat May 2 19:27:08 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 19:27:08 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FCC5DA.6000700@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> Message-ID: On Sat, 2 May 2009, Luis Moreira wrote: > Trent Jarvi wrote: >> >> >> On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: >> >>> Hi Travis, >>> The problem with the Makefile is not a problem,When I run ./configure >>> I make a new Makefile with the same data in it, hence what I just >>> modified is removed. >>> The issues I still have is the errors after that. Do you have any >>> idea what can be causing this errors? >>> >>> _______________________________________________________________________________ >>> >>> conftest.c: In function 'main': >>> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >>> function) >>> conftest.c:8: error: (Each undeclared identifier is reported only once >>> conftest.c:8: error: for each function it appears in.) >>> conftest.c:8: error: expected ')' before string constant >>> conftest.c:8: warning: format not a string literal and no format >>> arguments >>> ./configure: line 21462: ./conftest: No such file or directory >>> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >>> expected >>> configure: creating ./config.status >>> config.status: creating Makefile >>> config.status: creating config.h >>> config.status: config.h is unchanged >>> config.status: executing depfiles commands >>> ------------------------------------------------------------------------------- >>> >>> >>> >> >> This was corrected in CVS. I think you can just do the following in >> the top directory: >> >> cvs login: (pw is mousy) >> cvs update >> >> That will get the current fixes. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > apologies for the mix-up of your name. > I managed to get further on by updating CVS, the configure command gets > to the end without any errors, it still warns me that it is confused > about where to find the jni_md.h but I just edited the Makefile and > sorted that out. > I then run make, with no parameters following the instructions on the > Wiki, but that generated a few more errors: > ----------------------------------------------------------------------------------------------------------------------- > > gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. > -I/usr/lib/jvm/java-6-openjdk/include > /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE > -D_BSD_SOURCE -D__need_timespec -c > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o > /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' > undeclared (first use in this function) > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared > identifier is reported only once > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each > function it appears in.) > libtool: link: > `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a > valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 > ----------------------------------------------------------------------------------------------------------------------- > > Another question I have is, in which folder will the .so files be placed > after make finishes? > > thank you very much for your help. > Ah when you do cvs update pass the -Pd option cvs update -Pd Also, when you run configure, use --disable-PRINTER to only build the serial support. It will make things easier. --disable-LOCKFILES will also be easier to get going until you want to learn about how to prevent multiple applications from reading the same serial port. The link for debugging will describe where the files go. By default, it will install in the JRE/JDK under jre/lib/ext (the jar file) jre/lib/i386 (the .so file) Those are on the proper paths when you use the sun or ibm jdk. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sun May 3 01:30:43 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sun, 03 May 2009 08:30:43 +0100 Subject: [Rxtx] First use of RXTX package In-Reply-To: References: <49FCC5DA.6000700@ntlworld.com> Message-ID: <49FD4823.5080204@ntlworld.com> Ah > > when you do cvs update pass the -Pd option > > cvs update -Pd > > Also, when you run configure, use --disable-PRINTER to only build the > serial support. It will make things easier. --disable-LOCKFILES will > also be easier to get going until you want to learn about how to > prevent multiple applications from reading the same serial port. > > The link for debugging will describe where the files go. By default, > it will install in the JRE/JDK under > > jre/lib/ext (the jar file) > jre/lib/i386 (the .so file) > > Those are on the proper paths when you use the sun or ibm jdk. > > http://rxtx.qbang.org/wiki/index.php/Trouble_shooting > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, It as done it! I think this instructions you gave me should be on the Wiki, I can write them for you if you like. Also on the Wiki when you describe the three methods of installing the RxTx package it is confusing because as far as I can see, you always have to do method 1 or the .so files will not be generated(is this correct?). Then you can if you like change the location with method 1 & 2. Is it possible to modify the .la file to point to different directories for installation and then you can decide where to place the files? In a way I have learned quite a lot about Linux by having to struggle, with your help, to find solutions to the problems I encountered (I am still very new to Linux), but maybe we need to log these problems somewhere to make it less of a struggle for others like me. I have used the PortLister example to test it and it came up with my USB to dual Serial adaptor Ports. I will now explore the RxTx package, before I tackle the windows installation, I will let you know of my experience. Thank you for all your Help. Best Regards Luis From tjarvi at qbang.org Sun May 3 10:37:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 3 May 2009 10:37:50 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FD4823.5080204@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> <49FD4823.5080204@ntlworld.com> Message-ID: On Sun, 3 May 2009, Luis Moreira wrote: > Ah >> >> when you do cvs update pass the -Pd option >> >> cvs update -Pd >> >> Also, when you run configure, use --disable-PRINTER to only build the >> serial support. It will make things easier. --disable-LOCKFILES will >> also be easier to get going until you want to learn about how to >> prevent multiple applications from reading the same serial port. >> >> The link for debugging will describe where the files go. By default, >> it will install in the JRE/JDK under >> >> jre/lib/ext (the jar file) >> jre/lib/i386 (the .so file) >> >> Those are on the proper paths when you use the sun or ibm jdk. >> >> http://rxtx.qbang.org/wiki/index.php/Trouble_shooting >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > It as done it! > I think this instructions you gave me should be on the Wiki, I can write > them for you if you like. Also on the Wiki when you describe the three > methods of installing the RxTx package it is confusing because as far > as I can see, you always have to do method 1 or the .so files will not > be generated(is this correct?). Then you can if you like change the > location with method 1 & 2. Is it possible to modify the .la file to > point to different directories for installation and then you can decide > where to place the files? > In a way I have learned quite a lot about Linux by having to struggle, > with your help, to find solutions to the problems I encountered (I am > still very new to Linux), but maybe we need to log these problems > somewhere to make it less of a struggle for others like me. > > I have used the PortLister example to test it and it came up with my USB > to dual Serial adaptor Ports. > > I will now explore the RxTx package, before I tackle the windows > installation, I will let you know of my experience. > > Thank you for all your Help. > Hi Luis, The locations suggested for first time configuration could be documented in a new wiki page explaining that this is not the recommended general workflow but does help new users that are not worried about having rxtx installed into the JRE. For a professional environment, the user would want to follow the workflow currently on the wiki and keep their JRE clean. Often the user will not be able to add libraries to the JRE and will need to use their home directory or a sandbox. Feel free to add information to the wiki. I'd suggest creating comment in the current page and have the comment link to what worked for you as a first time user new to Linux. You can create a new page with your comments. In the long term, we will be working on an autoinstaller that works over the web. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Mon May 4 09:15:40 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Mon, 04 May 2009 16:15:40 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FF069C.8040406@ntlworld.com> Hi Trent, I have now installed the package on my 64 bit machine and when I run my program I get errors on the attachment. I know it as something to do with the architecture of my system but I can no figure out how to fix it. I have built it from source again, I did not transfer the files from machine to machine. can you please put me in the right direction. Thank you very much for your help. Best Regards Luis -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshoot.png Type: image/png Size: 25753 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090504/141ab5dc/attachment-0006.png From johnny.luong at trustcommerce.com Mon May 4 11:57:08 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 04 May 2009 10:57:08 -0700 Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FF069C.8040406@ntlworld.com> References: <49FF069C.8040406@ntlworld.com> Message-ID: <49FF2C74.90805@trustcommerce.com> Luis Moreira wrote: > Hi Trent, > I have now installed the package on my 64 bit machine and when I run my > program I get errors on the attachment. I know it as something to do > with the architecture of my system but I can no figure out how to fix > it. I have built it from source again, I did not transfer the files from > machine to machine. > can you please put me in the right direction. > Thank you very much for your help. > Best Regards > Luis > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Hi, Does running it on a 64-bit JVM help? Your host environment might be building objects for a 64-bit environment unless you did a cross-compile... -- you can find out by doing something like the following: johnny at spike:~$ java -version java version "1.6.0_0" OpenJDK Runtime Environment (build 1.6.0_0-b11) OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode) johnny at spike:~$ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) -Johnny From huangdongkai at gmail.com Wed May 6 11:06:06 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 01:06:06 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. Message-ID: Dear all, I recompile the rxtxSerial source code by MinGW32 and compile success. But when I run my Application which use rxtxSerial.dll to communicate with serial port, a runtime exception happened and application crash. I have no idea why it can not work, beacuse i have not change any source code of rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I have missed when compile the source code on Window NT? Here below is the output error massage. # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, tid=1360 # # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing windows-x86) # Problematic frame: # V [jvm.dll+0x1b6824] # # An error report file with more information is saved as: # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/32c1e699/attachment-0004.html From tjarvi at qbang.org Wed May 6 20:04:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 May 2009 20:04:10 -0600 (MDT) Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: On Thu, 7 May 2009, dongkai huang wrote: > Dear all, > ????? I recompile the rxtxSerial source code by MinGW32 and compile success. > But when I run my Application which use rxtxSerial.dll to communicate with > serial port, a runtime exception happened and application crash.? I have no > idea why it can not work, beacuse i have not change any source code of > rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I > have missed when compile the source code on Window NT? Here below is the > output error massage. > # > # An unexpected error has been detected by Java Runtime Environment: > # > #? EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, > tid=1360 > # > # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing > windows-x86) > > # Problematic frame: > # V? [jvm.dll+0x1b6824] > # > # An error report file with more information is saved as: > # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log > # > # If you would like to submit a bug report, please visit: > #?? http://java.sun.com/webapps/bugreport/crash.jsp > # > > > Hi Dongkai Could you explain how you compiled rxtx with mingw? Did you run configure? Was the compiler native or a cross compiler (like compiling on Linux for Windows)? Is the crash happening when you first open the port or is it happening randomly later on? -- Trent Jarvi tjarvi at qbang.org From huangdongkai at gmail.com Wed May 6 20:48:56 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 10:48:56 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Hi Trent, I was followed the step on INSTALL file, did not run the configure, I used the Makefile.mingw32 which include on the source code package, and only change some path( jdk home path etc.). And I use the native compiler on Windows. The crash happened on I call the getPortIdentifiers() every time. On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Dear all, >> I recompile the rxtxSerial source code by MinGW32 and compile >> success. >> But when I run my Application which use rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and application crash. I have >> no >> idea why it can not work, beacuse i have not change any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing >> I >> have missed when compile the source code on Window NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is saved as: >> # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> > Hi Dongkai > > Could you explain how you compiled rxtx with mingw? Did you run configure? > Was the compiler native or a cross compiler (like compiling on Linux for > Windows)? > > Is the crash happening when you first open the port or is it happening > randomly later on? > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/733eded5/attachment-0004.html From m.j.tandy at warwick.ac.uk Thu May 7 10:39:12 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 7 May 2009 17:39:12 +0100 Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. Message-ID: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> I've encountered a bug in how XON/XOFF are handled on Windows. The symptoms were: 1. XON/XOFF from device to PC did not stop transmission. 2. XON/XOFF characters were present in data read from serial port input stream, when it was expected that they would be stripped out. 3. Investigation with SysInternals PortMon revealed the following configuration when using rxtx: 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 while HyperTerminal, which did not have the same problems as me, produced the following: 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 In other words, the problem is that, in addition to being told to use XON/XOFF flow control, the computer has to explicitly be told which characters to use for 'XON' and 'XOFF'. This part of the configuration was being missed out. I got the latest rxtx source from CVS, and identified the problem as an omission in the 'init_termios' function of 'termios.c', which configures the unix/termios 'c_cc' (control characters) data structure - but omits to configure the VSTART and VSTOP control characters. Later, the termios c_cc data structure is translated (by termios_to_DCB) into a data structure named 'DCB', which is passed to the windows serial port configuration interface. By adding two lines defining the standard XON/XOFF characters to the function init_termios, the bug is fixed. A patch doing this is attached. Thanks, Michael Tandy -------------- next part -------------- A non-text attachment was scrubbed... Name: xon-xoff.diff Type: application/octet-stream Size: 667 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/159c0dcc/attachment-0003.obj From tjarvi at qbang.org Thu May 7 17:57:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 May 2009 17:57:28 -0600 (MDT) Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. In-Reply-To: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> References: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> Message-ID: On Thu, 7 May 2009, Michael Tandy wrote: > I've encountered a bug in how XON/XOFF are handled on Windows. > > The symptoms were: > 1. XON/XOFF from device to PC did not stop transmission. > 2. XON/XOFF characters were present in data read from serial port > input stream, when it was expected that they would be stripped out. > 3. Investigation with SysInternals PortMon revealed the following > configuration when using rxtx: > > 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 > BRK:0 EVT:a XON:0 XOFF:0 > > while HyperTerminal, which did not have the same problems as me, > produced the following: > > 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 > > In other words, the problem is that, in addition to being told to use > XON/XOFF flow control, the computer has to explicitly be told which > characters to use for 'XON' and 'XOFF'. This part of the configuration > was being missed out. > > I got the latest rxtx source from CVS, and identified the problem as > an omission in the 'init_termios' function of 'termios.c', which > configures the unix/termios 'c_cc' (control characters) data structure > - but omits to configure the VSTART and VSTOP control characters. > Later, the termios c_cc data structure is translated (by > termios_to_DCB) into a data structure named 'DCB', which is passed to > the windows serial port configuration interface. > > By adding two lines defining the standard XON/XOFF characters to the > function init_termios, the bug is fixed. A patch doing this is > attached. > Thanks Michael, Good timing. I plan on releasing rxtx-2.2 this coming Sunday. -- Trent Jarvi tjarvi at qbang.org From wjr at weru.ksu.edu Fri May 8 11:38:29 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Fri, 08 May 2009 12:38:29 -0500 Subject: [Rxtx] swing jfilechooser lockup Message-ID: <4A046E15.6010907@weru.ksu.edu> Hi, I wrote a small swing app to download images from an industrial camera. I used the two way serial sample code as a starting point. The app works fine EXCEPT for a call to jfilechooser. After I open the comm port and then try to change the output directory or log file, the jfilechooser winds up trying to unpark (note, parking is not something I'm really familiar with) and doesn't. If I try to change the file or directory before I start the comm port, it works. If I click on menu items that don't call jfilechooser, everything is OK. If I try closing the comm port and then try to create a jfilechooser, it locks up. There is obviously some sort of deadlock here because the awt thread starts waiting on something but it's not clear what. I haven't gone thru the rxtx code yet because it's not in the file structure that netbeans wants for debugging purposes. However, debugging code that I don't have a clear idea of what it is supposed to do is not my idea of a good time. Does anyone have any ideas on what is going on here? Thanks, wjr From Bob_Jacobsen at lbl.gov Fri May 8 14:48:25 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Fri, 8 May 2009 13:48:25 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A046E15.6010907@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> Message-ID: At 12:38 PM -0500 5/8/09, Bill Rust wrote: >Hi, > >I wrote a small swing app to download images from an industrial camera. >I used the two way serial sample code as a starting point. The app works >fine EXCEPT for a call to jfilechooser. After I open the comm port and >then try to change the output directory or log file, the jfilechooser >winds up trying to unpark (note, parking is not something I'm really >familiar with) and doesn't. If I try to change the file or directory >before I start the comm port, it works. If I click on menu items that >don't call jfilechooser, everything is OK. If I try closing the comm >port and then try to create a jfilechooser, it locks up. There is >obviously some sort of deadlock here because the awt thread starts >waiting on something but it's not clear what. I haven't gone thru the >rxtx code yet because it's not in the file structure that netbeans wants >for debugging purposes. However, debugging code that I don't have a >clear idea of what it is supposed to do is not my idea of a good time. What is the threading structure of your code? The various high-function Swing components, such as JFileChooser, are notorious for doing Really Bad Stuff when invoked from off the Swing thread. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From bschlining at gmail.com Fri May 8 15:08:50 2009 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 8 May 2009 14:08:50 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: Bob's probably right...take look at javax.swing.SwingUtilites for the workaround to get your swing stuff invoked on the EventDispatchThread (EDT). Some swing-methods do work when called outside of the EDT, but just to be safe, do your creation and swing calls on the EDT. It's really simple, here's an example of a synchronous call. // Here's how to run stuff on the EDT from a different thread SwingUtilities.invokeAndWait(new Runnable() { public void run() { JFileChooser fc; // create, setup, show your filechooser // Get the result from the filechooser } }); To do a asynchronous call use SwingUtilities.invokeLater > >I wrote a small swing app to download images from an industrial camera. > >I used the two way serial sample code as a starting point. The app works > >fine EXCEPT for a call to jfilechooser. After I open the comm port and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090508/c21c2127/attachment-0002.html From tod at todbot.com Fri May 8 16:27:12 2009 From: tod at todbot.com (Tod E. Kurt) Date: Fri, 8 May 2009 15:27:12 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> This is the exact technique I use to let the user choose which serial port to use on startup. Here's a method I've got in many of my sketches: void choosePort() { String portlist[] = Serial.list(); String port = null; javax.swing.SwingUtilities.invokeLater(new Runnable() { public void run() { try { String port = (String) javax.swing.JOptionPane.showInputDialog( null, "Select Serial Port", "MySuperSketch", javax.swing.JOptionPane.QUESTION_MESSAGE, null, portlist, null); if( port == null ) { javax.swing.JOptionPane.showMessageDialog(null, "No port chosen, goodbye"); System.exit(1); } serialPort = port; } catch (Exception e) { e.printStackTrace(); } } } ); } On May 8, 2009, at 2:08 p, Brian Schlining wrote: > Bob's probably right...take look at javax.swing.SwingUtilites for > the workaround to get your swing stuff invoked on the > EventDispatchThread (EDT). Some swing-methods do work when called > outside of the EDT, but just to be safe, do your creation and swing > calls on the EDT. It's really simple, here's an example of a > synchronous call. > > // Here's how to run stuff on the EDT from a different thread > SwingUtilities.invokeAndWait(new Runnable() { > public void run() { > JFileChooser fc; // create, setup, show your filechooser > // Get the result from the filechooser > } > }); > > To do a asynchronous call use SwingUtilities.invokeLater > > > >I wrote a small swing app to download images from an industrial > camera. > >I used the two way serial sample code as a starting point. The app > works > >fine EXCEPT for a call to jfilechooser. After I open the comm port > and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From huangdongkai at gmail.com Sat May 9 04:46:22 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Sat, 9 May 2009 18:46:22 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Dear Trent, After I intsall the ming32-cross compile to compile the rxtxSerial.dll and testing, i found the same problem still exist. I am not sure my compiler version is the same as your's. Could you tell me the way you can success compile rxtx-2.1-7r2 release source code? Thanks for you kindly help. On Fri, May 8, 2009 at 8:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Hi Trent, >> The attach is the Make file I use to compile the rxtx. >> >> On Thu, May 7, 2009 at 10:48 AM, dongkai huang >> wrote: >> Hi Trent, >> I was followed the step on INSTALL file, did not run the >> configure, I used the Makefile.mingw32 which include on the >> source code package, and only change some path( jdk home path >> etc.). And I use the native compiler on Windows. >> The crash happened on I call the getPortIdentifiers() >> every time. >> >> On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: >> >> >> On Thu, 7 May 2009, dongkai huang wrote: >> >> Dear all, >> I recompile the rxtxSerial source code by >> MinGW32 and compile success. >> But when I run my Application which use >> rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and >> application crash. I have no >> idea why it can not work, beacuse i have not change >> any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source >> code. Did some thing I >> have missed when compile the source code on Window >> NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java >> Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at >> pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 >> mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is >> saved as: >> # >> D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please >> visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> >> Hi Dongkai >> >> Could you explain how you compiled rxtx with mingw? Did you run >> configure? Was the compiler native or a cross compiler (like >> compiling on Linux for Windows)? >> >> Is the crash happening when you first open the port or is it >> happening randomly later on? >> >> > Thanks Dongkai > > I'll look at your Makefile tomorrow. Which version of mingw was this? > > I suspect there is a problem with that makefile. I usually built that > version of rxtx for windows with a mingw32 cross compiler using the > configure script. > > The configure script may well work for you if you have a cygwin environment > with mingw instead of gcc. I'll take a look at what is different. > > -- > > Trent Jarvi > tjarvi at qbang.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090509/b729c429/attachment-0001.html From luis.moreira at ntlworld.com Sat May 2 00:39:04 2009 From: luis.moreira at ntlworld.com (luis.moreira at ntlworld.com) Date: Sat, 2 May 2009 7:39:04 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Hi Travis, The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. The issues I still have is the errors after that. Do you have any idea what can be causing this errors? _______________________________________________________________________________ conftest.c: In function 'main': conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) conftest.c:8: error: (Each undeclared identifier is reported only once conftest.c:8: error: for each function it appears in.) conftest.c:8: error: expected ')' before string constant conftest.c:8: warning: format not a string literal and no format arguments ./configure: line 21462: ./conftest: No such file or directory ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands ------------------------------------------------------------------------------- I don't know what happened to my previous post, it as not showed up in the list. Best Regards Luis From tjarvi at qbang.org Sat May 2 07:30:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 07:30:04 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> References: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Message-ID: On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > Hi Travis, > The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. > The issues I still have is the errors after that. Do you have any idea what can be causing this errors? > > _______________________________________________________________________________ > conftest.c: In function 'main': > conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) > conftest.c:8: error: (Each undeclared identifier is reported only once > conftest.c:8: error: for each function it appears in.) > conftest.c:8: error: expected ')' before string constant > conftest.c:8: warning: format not a string literal and no format arguments > ./configure: line 21462: ./conftest: No such file or directory > ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: config.h is unchanged > config.status: executing depfiles commands > ------------------------------------------------------------------------------- > > This was corrected in CVS. I think you can just do the following in the top directory: cvs login: (pw is mousy) cvs update That will get the current fixes. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sat May 2 16:14:50 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sat, 02 May 2009 23:14:50 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FCC5DA.6000700@ntlworld.com> Trent Jarvi wrote: > > > On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > >> Hi Travis, >> The problem with the Makefile is not a problem,When I run ./configure >> I make a new Makefile with the same data in it, hence what I just >> modified is removed. >> The issues I still have is the errors after that. Do you have any >> idea what can be causing this errors? >> >> _______________________________________________________________________________ >> >> conftest.c: In function 'main': >> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >> function) >> conftest.c:8: error: (Each undeclared identifier is reported only once >> conftest.c:8: error: for each function it appears in.) >> conftest.c:8: error: expected ')' before string constant >> conftest.c:8: warning: format not a string literal and no format >> arguments >> ./configure: line 21462: ./conftest: No such file or directory >> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >> expected >> configure: creating ./config.status >> config.status: creating Makefile >> config.status: creating config.h >> config.status: config.h is unchanged >> config.status: executing depfiles commands >> ------------------------------------------------------------------------------- >> >> >> > > This was corrected in CVS. I think you can just do the following in > the top directory: > > cvs login: (pw is mousy) > cvs update > > That will get the current fixes. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, apologies for the mix-up of your name. I managed to get further on by updating CVS, the configure command gets to the end without any errors, it still warns me that it is confused about where to find the jni_md.h but I just edited the Makefile and sorted that out. I then run make, with no parameters following the instructions on the Wiki, but that generated a few more errors: ----------------------------------------------------------------------------------------------------------------------- gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. -I/usr/lib/jvm/java-6-openjdk/include /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' undeclared (first use in this function) /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared identifier is reported only once /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each function it appears in.) libtool: link: `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 ----------------------------------------------------------------------------------------------------------------------- Another question I have is, in which folder will the .so files be placed after make finishes? thank you very much for your help. Best Regards Luis From tjarvi at qbang.org Sat May 2 19:27:08 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 19:27:08 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FCC5DA.6000700@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> Message-ID: On Sat, 2 May 2009, Luis Moreira wrote: > Trent Jarvi wrote: >> >> >> On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: >> >>> Hi Travis, >>> The problem with the Makefile is not a problem,When I run ./configure >>> I make a new Makefile with the same data in it, hence what I just >>> modified is removed. >>> The issues I still have is the errors after that. Do you have any >>> idea what can be causing this errors? >>> >>> _______________________________________________________________________________ >>> >>> conftest.c: In function 'main': >>> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >>> function) >>> conftest.c:8: error: (Each undeclared identifier is reported only once >>> conftest.c:8: error: for each function it appears in.) >>> conftest.c:8: error: expected ')' before string constant >>> conftest.c:8: warning: format not a string literal and no format >>> arguments >>> ./configure: line 21462: ./conftest: No such file or directory >>> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >>> expected >>> configure: creating ./config.status >>> config.status: creating Makefile >>> config.status: creating config.h >>> config.status: config.h is unchanged >>> config.status: executing depfiles commands >>> ------------------------------------------------------------------------------- >>> >>> >>> >> >> This was corrected in CVS. I think you can just do the following in >> the top directory: >> >> cvs login: (pw is mousy) >> cvs update >> >> That will get the current fixes. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > apologies for the mix-up of your name. > I managed to get further on by updating CVS, the configure command gets > to the end without any errors, it still warns me that it is confused > about where to find the jni_md.h but I just edited the Makefile and > sorted that out. > I then run make, with no parameters following the instructions on the > Wiki, but that generated a few more errors: > ----------------------------------------------------------------------------------------------------------------------- > > gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. > -I/usr/lib/jvm/java-6-openjdk/include > /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE > -D_BSD_SOURCE -D__need_timespec -c > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o > /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' > undeclared (first use in this function) > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared > identifier is reported only once > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each > function it appears in.) > libtool: link: > `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a > valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 > ----------------------------------------------------------------------------------------------------------------------- > > Another question I have is, in which folder will the .so files be placed > after make finishes? > > thank you very much for your help. > Ah when you do cvs update pass the -Pd option cvs update -Pd Also, when you run configure, use --disable-PRINTER to only build the serial support. It will make things easier. --disable-LOCKFILES will also be easier to get going until you want to learn about how to prevent multiple applications from reading the same serial port. The link for debugging will describe where the files go. By default, it will install in the JRE/JDK under jre/lib/ext (the jar file) jre/lib/i386 (the .so file) Those are on the proper paths when you use the sun or ibm jdk. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sun May 3 01:30:43 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sun, 03 May 2009 08:30:43 +0100 Subject: [Rxtx] First use of RXTX package In-Reply-To: References: <49FCC5DA.6000700@ntlworld.com> Message-ID: <49FD4823.5080204@ntlworld.com> Ah > > when you do cvs update pass the -Pd option > > cvs update -Pd > > Also, when you run configure, use --disable-PRINTER to only build the > serial support. It will make things easier. --disable-LOCKFILES will > also be easier to get going until you want to learn about how to > prevent multiple applications from reading the same serial port. > > The link for debugging will describe where the files go. By default, > it will install in the JRE/JDK under > > jre/lib/ext (the jar file) > jre/lib/i386 (the .so file) > > Those are on the proper paths when you use the sun or ibm jdk. > > http://rxtx.qbang.org/wiki/index.php/Trouble_shooting > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, It as done it! I think this instructions you gave me should be on the Wiki, I can write them for you if you like. Also on the Wiki when you describe the three methods of installing the RxTx package it is confusing because as far as I can see, you always have to do method 1 or the .so files will not be generated(is this correct?). Then you can if you like change the location with method 1 & 2. Is it possible to modify the .la file to point to different directories for installation and then you can decide where to place the files? In a way I have learned quite a lot about Linux by having to struggle, with your help, to find solutions to the problems I encountered (I am still very new to Linux), but maybe we need to log these problems somewhere to make it less of a struggle for others like me. I have used the PortLister example to test it and it came up with my USB to dual Serial adaptor Ports. I will now explore the RxTx package, before I tackle the windows installation, I will let you know of my experience. Thank you for all your Help. Best Regards Luis From tjarvi at qbang.org Sun May 3 10:37:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 3 May 2009 10:37:50 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FD4823.5080204@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> <49FD4823.5080204@ntlworld.com> Message-ID: On Sun, 3 May 2009, Luis Moreira wrote: > Ah >> >> when you do cvs update pass the -Pd option >> >> cvs update -Pd >> >> Also, when you run configure, use --disable-PRINTER to only build the >> serial support. It will make things easier. --disable-LOCKFILES will >> also be easier to get going until you want to learn about how to >> prevent multiple applications from reading the same serial port. >> >> The link for debugging will describe where the files go. By default, >> it will install in the JRE/JDK under >> >> jre/lib/ext (the jar file) >> jre/lib/i386 (the .so file) >> >> Those are on the proper paths when you use the sun or ibm jdk. >> >> http://rxtx.qbang.org/wiki/index.php/Trouble_shooting >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > It as done it! > I think this instructions you gave me should be on the Wiki, I can write > them for you if you like. Also on the Wiki when you describe the three > methods of installing the RxTx package it is confusing because as far > as I can see, you always have to do method 1 or the .so files will not > be generated(is this correct?). Then you can if you like change the > location with method 1 & 2. Is it possible to modify the .la file to > point to different directories for installation and then you can decide > where to place the files? > In a way I have learned quite a lot about Linux by having to struggle, > with your help, to find solutions to the problems I encountered (I am > still very new to Linux), but maybe we need to log these problems > somewhere to make it less of a struggle for others like me. > > I have used the PortLister example to test it and it came up with my USB > to dual Serial adaptor Ports. > > I will now explore the RxTx package, before I tackle the windows > installation, I will let you know of my experience. > > Thank you for all your Help. > Hi Luis, The locations suggested for first time configuration could be documented in a new wiki page explaining that this is not the recommended general workflow but does help new users that are not worried about having rxtx installed into the JRE. For a professional environment, the user would want to follow the workflow currently on the wiki and keep their JRE clean. Often the user will not be able to add libraries to the JRE and will need to use their home directory or a sandbox. Feel free to add information to the wiki. I'd suggest creating comment in the current page and have the comment link to what worked for you as a first time user new to Linux. You can create a new page with your comments. In the long term, we will be working on an autoinstaller that works over the web. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Mon May 4 09:15:40 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Mon, 04 May 2009 16:15:40 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FF069C.8040406@ntlworld.com> Hi Trent, I have now installed the package on my 64 bit machine and when I run my program I get errors on the attachment. I know it as something to do with the architecture of my system but I can no figure out how to fix it. I have built it from source again, I did not transfer the files from machine to machine. can you please put me in the right direction. Thank you very much for your help. Best Regards Luis -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshoot.png Type: image/png Size: 25753 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090504/141ab5dc/attachment-0007.png From johnny.luong at trustcommerce.com Mon May 4 11:57:08 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 04 May 2009 10:57:08 -0700 Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FF069C.8040406@ntlworld.com> References: <49FF069C.8040406@ntlworld.com> Message-ID: <49FF2C74.90805@trustcommerce.com> Luis Moreira wrote: > Hi Trent, > I have now installed the package on my 64 bit machine and when I run my > program I get errors on the attachment. I know it as something to do > with the architecture of my system but I can no figure out how to fix > it. I have built it from source again, I did not transfer the files from > machine to machine. > can you please put me in the right direction. > Thank you very much for your help. > Best Regards > Luis > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Hi, Does running it on a 64-bit JVM help? Your host environment might be building objects for a 64-bit environment unless you did a cross-compile... -- you can find out by doing something like the following: johnny at spike:~$ java -version java version "1.6.0_0" OpenJDK Runtime Environment (build 1.6.0_0-b11) OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode) johnny at spike:~$ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) -Johnny From huangdongkai at gmail.com Wed May 6 11:06:06 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 01:06:06 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. Message-ID: Dear all, I recompile the rxtxSerial source code by MinGW32 and compile success. But when I run my Application which use rxtxSerial.dll to communicate with serial port, a runtime exception happened and application crash. I have no idea why it can not work, beacuse i have not change any source code of rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I have missed when compile the source code on Window NT? Here below is the output error massage. # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, tid=1360 # # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing windows-x86) # Problematic frame: # V [jvm.dll+0x1b6824] # # An error report file with more information is saved as: # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/32c1e699/attachment-0005.html From tjarvi at qbang.org Wed May 6 20:04:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 May 2009 20:04:10 -0600 (MDT) Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: On Thu, 7 May 2009, dongkai huang wrote: > Dear all, > ????? I recompile the rxtxSerial source code by MinGW32 and compile success. > But when I run my Application which use rxtxSerial.dll to communicate with > serial port, a runtime exception happened and application crash.? I have no > idea why it can not work, beacuse i have not change any source code of > rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I > have missed when compile the source code on Window NT? Here below is the > output error massage. > # > # An unexpected error has been detected by Java Runtime Environment: > # > #? EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, > tid=1360 > # > # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing > windows-x86) > > # Problematic frame: > # V? [jvm.dll+0x1b6824] > # > # An error report file with more information is saved as: > # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log > # > # If you would like to submit a bug report, please visit: > #?? http://java.sun.com/webapps/bugreport/crash.jsp > # > > > Hi Dongkai Could you explain how you compiled rxtx with mingw? Did you run configure? Was the compiler native or a cross compiler (like compiling on Linux for Windows)? Is the crash happening when you first open the port or is it happening randomly later on? -- Trent Jarvi tjarvi at qbang.org From huangdongkai at gmail.com Wed May 6 20:48:56 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 10:48:56 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Hi Trent, I was followed the step on INSTALL file, did not run the configure, I used the Makefile.mingw32 which include on the source code package, and only change some path( jdk home path etc.). And I use the native compiler on Windows. The crash happened on I call the getPortIdentifiers() every time. On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Dear all, >> I recompile the rxtxSerial source code by MinGW32 and compile >> success. >> But when I run my Application which use rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and application crash. I have >> no >> idea why it can not work, beacuse i have not change any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing >> I >> have missed when compile the source code on Window NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is saved as: >> # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> > Hi Dongkai > > Could you explain how you compiled rxtx with mingw? Did you run configure? > Was the compiler native or a cross compiler (like compiling on Linux for > Windows)? > > Is the crash happening when you first open the port or is it happening > randomly later on? > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/733eded5/attachment-0005.html From m.j.tandy at warwick.ac.uk Thu May 7 10:39:12 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 7 May 2009 17:39:12 +0100 Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. Message-ID: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> I've encountered a bug in how XON/XOFF are handled on Windows. The symptoms were: 1. XON/XOFF from device to PC did not stop transmission. 2. XON/XOFF characters were present in data read from serial port input stream, when it was expected that they would be stripped out. 3. Investigation with SysInternals PortMon revealed the following configuration when using rxtx: 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 while HyperTerminal, which did not have the same problems as me, produced the following: 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 In other words, the problem is that, in addition to being told to use XON/XOFF flow control, the computer has to explicitly be told which characters to use for 'XON' and 'XOFF'. This part of the configuration was being missed out. I got the latest rxtx source from CVS, and identified the problem as an omission in the 'init_termios' function of 'termios.c', which configures the unix/termios 'c_cc' (control characters) data structure - but omits to configure the VSTART and VSTOP control characters. Later, the termios c_cc data structure is translated (by termios_to_DCB) into a data structure named 'DCB', which is passed to the windows serial port configuration interface. By adding two lines defining the standard XON/XOFF characters to the function init_termios, the bug is fixed. A patch doing this is attached. Thanks, Michael Tandy -------------- next part -------------- A non-text attachment was scrubbed... Name: xon-xoff.diff Type: application/octet-stream Size: 667 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/159c0dcc/attachment-0004.obj From tjarvi at qbang.org Thu May 7 17:57:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 May 2009 17:57:28 -0600 (MDT) Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. In-Reply-To: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> References: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> Message-ID: On Thu, 7 May 2009, Michael Tandy wrote: > I've encountered a bug in how XON/XOFF are handled on Windows. > > The symptoms were: > 1. XON/XOFF from device to PC did not stop transmission. > 2. XON/XOFF characters were present in data read from serial port > input stream, when it was expected that they would be stripped out. > 3. Investigation with SysInternals PortMon revealed the following > configuration when using rxtx: > > 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 > BRK:0 EVT:a XON:0 XOFF:0 > > while HyperTerminal, which did not have the same problems as me, > produced the following: > > 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 > > In other words, the problem is that, in addition to being told to use > XON/XOFF flow control, the computer has to explicitly be told which > characters to use for 'XON' and 'XOFF'. This part of the configuration > was being missed out. > > I got the latest rxtx source from CVS, and identified the problem as > an omission in the 'init_termios' function of 'termios.c', which > configures the unix/termios 'c_cc' (control characters) data structure > - but omits to configure the VSTART and VSTOP control characters. > Later, the termios c_cc data structure is translated (by > termios_to_DCB) into a data structure named 'DCB', which is passed to > the windows serial port configuration interface. > > By adding two lines defining the standard XON/XOFF characters to the > function init_termios, the bug is fixed. A patch doing this is > attached. > Thanks Michael, Good timing. I plan on releasing rxtx-2.2 this coming Sunday. -- Trent Jarvi tjarvi at qbang.org From wjr at weru.ksu.edu Fri May 8 11:38:29 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Fri, 08 May 2009 12:38:29 -0500 Subject: [Rxtx] swing jfilechooser lockup Message-ID: <4A046E15.6010907@weru.ksu.edu> Hi, I wrote a small swing app to download images from an industrial camera. I used the two way serial sample code as a starting point. The app works fine EXCEPT for a call to jfilechooser. After I open the comm port and then try to change the output directory or log file, the jfilechooser winds up trying to unpark (note, parking is not something I'm really familiar with) and doesn't. If I try to change the file or directory before I start the comm port, it works. If I click on menu items that don't call jfilechooser, everything is OK. If I try closing the comm port and then try to create a jfilechooser, it locks up. There is obviously some sort of deadlock here because the awt thread starts waiting on something but it's not clear what. I haven't gone thru the rxtx code yet because it's not in the file structure that netbeans wants for debugging purposes. However, debugging code that I don't have a clear idea of what it is supposed to do is not my idea of a good time. Does anyone have any ideas on what is going on here? Thanks, wjr From Bob_Jacobsen at lbl.gov Fri May 8 14:48:25 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Fri, 8 May 2009 13:48:25 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A046E15.6010907@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> Message-ID: At 12:38 PM -0500 5/8/09, Bill Rust wrote: >Hi, > >I wrote a small swing app to download images from an industrial camera. >I used the two way serial sample code as a starting point. The app works >fine EXCEPT for a call to jfilechooser. After I open the comm port and >then try to change the output directory or log file, the jfilechooser >winds up trying to unpark (note, parking is not something I'm really >familiar with) and doesn't. If I try to change the file or directory >before I start the comm port, it works. If I click on menu items that >don't call jfilechooser, everything is OK. If I try closing the comm >port and then try to create a jfilechooser, it locks up. There is >obviously some sort of deadlock here because the awt thread starts >waiting on something but it's not clear what. I haven't gone thru the >rxtx code yet because it's not in the file structure that netbeans wants >for debugging purposes. However, debugging code that I don't have a >clear idea of what it is supposed to do is not my idea of a good time. What is the threading structure of your code? The various high-function Swing components, such as JFileChooser, are notorious for doing Really Bad Stuff when invoked from off the Swing thread. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From bschlining at gmail.com Fri May 8 15:08:50 2009 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 8 May 2009 14:08:50 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: Bob's probably right...take look at javax.swing.SwingUtilites for the workaround to get your swing stuff invoked on the EventDispatchThread (EDT). Some swing-methods do work when called outside of the EDT, but just to be safe, do your creation and swing calls on the EDT. It's really simple, here's an example of a synchronous call. // Here's how to run stuff on the EDT from a different thread SwingUtilities.invokeAndWait(new Runnable() { public void run() { JFileChooser fc; // create, setup, show your filechooser // Get the result from the filechooser } }); To do a asynchronous call use SwingUtilities.invokeLater > >I wrote a small swing app to download images from an industrial camera. > >I used the two way serial sample code as a starting point. The app works > >fine EXCEPT for a call to jfilechooser. After I open the comm port and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090508/c21c2127/attachment-0003.html From tod at todbot.com Fri May 8 16:27:12 2009 From: tod at todbot.com (Tod E. Kurt) Date: Fri, 8 May 2009 15:27:12 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> This is the exact technique I use to let the user choose which serial port to use on startup. Here's a method I've got in many of my sketches: void choosePort() { String portlist[] = Serial.list(); String port = null; javax.swing.SwingUtilities.invokeLater(new Runnable() { public void run() { try { String port = (String) javax.swing.JOptionPane.showInputDialog( null, "Select Serial Port", "MySuperSketch", javax.swing.JOptionPane.QUESTION_MESSAGE, null, portlist, null); if( port == null ) { javax.swing.JOptionPane.showMessageDialog(null, "No port chosen, goodbye"); System.exit(1); } serialPort = port; } catch (Exception e) { e.printStackTrace(); } } } ); } On May 8, 2009, at 2:08 p, Brian Schlining wrote: > Bob's probably right...take look at javax.swing.SwingUtilites for > the workaround to get your swing stuff invoked on the > EventDispatchThread (EDT). Some swing-methods do work when called > outside of the EDT, but just to be safe, do your creation and swing > calls on the EDT. It's really simple, here's an example of a > synchronous call. > > // Here's how to run stuff on the EDT from a different thread > SwingUtilities.invokeAndWait(new Runnable() { > public void run() { > JFileChooser fc; // create, setup, show your filechooser > // Get the result from the filechooser > } > }); > > To do a asynchronous call use SwingUtilities.invokeLater > > > >I wrote a small swing app to download images from an industrial > camera. > >I used the two way serial sample code as a starting point. The app > works > >fine EXCEPT for a call to jfilechooser. After I open the comm port > and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From huangdongkai at gmail.com Sat May 9 04:46:22 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Sat, 9 May 2009 18:46:22 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Dear Trent, After I intsall the ming32-cross compile to compile the rxtxSerial.dll and testing, i found the same problem still exist. I am not sure my compiler version is the same as your's. Could you tell me the way you can success compile rxtx-2.1-7r2 release source code? Thanks for you kindly help. On Fri, May 8, 2009 at 8:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Hi Trent, >> The attach is the Make file I use to compile the rxtx. >> >> On Thu, May 7, 2009 at 10:48 AM, dongkai huang >> wrote: >> Hi Trent, >> I was followed the step on INSTALL file, did not run the >> configure, I used the Makefile.mingw32 which include on the >> source code package, and only change some path( jdk home path >> etc.). And I use the native compiler on Windows. >> The crash happened on I call the getPortIdentifiers() >> every time. >> >> On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: >> >> >> On Thu, 7 May 2009, dongkai huang wrote: >> >> Dear all, >> I recompile the rxtxSerial source code by >> MinGW32 and compile success. >> But when I run my Application which use >> rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and >> application crash. I have no >> idea why it can not work, beacuse i have not change >> any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source >> code. Did some thing I >> have missed when compile the source code on Window >> NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java >> Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at >> pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 >> mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is >> saved as: >> # >> D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please >> visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> >> Hi Dongkai >> >> Could you explain how you compiled rxtx with mingw? Did you run >> configure? Was the compiler native or a cross compiler (like >> compiling on Linux for Windows)? >> >> Is the crash happening when you first open the port or is it >> happening randomly later on? >> >> > Thanks Dongkai > > I'll look at your Makefile tomorrow. Which version of mingw was this? > > I suspect there is a problem with that makefile. I usually built that > version of rxtx for windows with a mingw32 cross compiler using the > configure script. > > The configure script may well work for you if you have a cygwin environment > with mingw instead of gcc. I'll take a look at what is different. > > -- > > Trent Jarvi > tjarvi at qbang.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090509/b729c429/attachment-0002.html From luis.moreira at ntlworld.com Sat May 2 00:39:04 2009 From: luis.moreira at ntlworld.com (luis.moreira at ntlworld.com) Date: Sat, 2 May 2009 7:39:04 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Hi Travis, The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. The issues I still have is the errors after that. Do you have any idea what can be causing this errors? _______________________________________________________________________________ conftest.c: In function 'main': conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) conftest.c:8: error: (Each undeclared identifier is reported only once conftest.c:8: error: for each function it appears in.) conftest.c:8: error: expected ')' before string constant conftest.c:8: warning: format not a string literal and no format arguments ./configure: line 21462: ./conftest: No such file or directory ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands ------------------------------------------------------------------------------- I don't know what happened to my previous post, it as not showed up in the list. Best Regards Luis From tjarvi at qbang.org Sat May 2 07:30:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 07:30:04 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> References: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Message-ID: On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > Hi Travis, > The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. > The issues I still have is the errors after that. Do you have any idea what can be causing this errors? > > _______________________________________________________________________________ > conftest.c: In function 'main': > conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) > conftest.c:8: error: (Each undeclared identifier is reported only once > conftest.c:8: error: for each function it appears in.) > conftest.c:8: error: expected ')' before string constant > conftest.c:8: warning: format not a string literal and no format arguments > ./configure: line 21462: ./conftest: No such file or directory > ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: config.h is unchanged > config.status: executing depfiles commands > ------------------------------------------------------------------------------- > > This was corrected in CVS. I think you can just do the following in the top directory: cvs login: (pw is mousy) cvs update That will get the current fixes. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sat May 2 16:14:50 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sat, 02 May 2009 23:14:50 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FCC5DA.6000700@ntlworld.com> Trent Jarvi wrote: > > > On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > >> Hi Travis, >> The problem with the Makefile is not a problem,When I run ./configure >> I make a new Makefile with the same data in it, hence what I just >> modified is removed. >> The issues I still have is the errors after that. Do you have any >> idea what can be causing this errors? >> >> _______________________________________________________________________________ >> >> conftest.c: In function 'main': >> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >> function) >> conftest.c:8: error: (Each undeclared identifier is reported only once >> conftest.c:8: error: for each function it appears in.) >> conftest.c:8: error: expected ')' before string constant >> conftest.c:8: warning: format not a string literal and no format >> arguments >> ./configure: line 21462: ./conftest: No such file or directory >> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >> expected >> configure: creating ./config.status >> config.status: creating Makefile >> config.status: creating config.h >> config.status: config.h is unchanged >> config.status: executing depfiles commands >> ------------------------------------------------------------------------------- >> >> >> > > This was corrected in CVS. I think you can just do the following in > the top directory: > > cvs login: (pw is mousy) > cvs update > > That will get the current fixes. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, apologies for the mix-up of your name. I managed to get further on by updating CVS, the configure command gets to the end without any errors, it still warns me that it is confused about where to find the jni_md.h but I just edited the Makefile and sorted that out. I then run make, with no parameters following the instructions on the Wiki, but that generated a few more errors: ----------------------------------------------------------------------------------------------------------------------- gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. -I/usr/lib/jvm/java-6-openjdk/include /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' undeclared (first use in this function) /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared identifier is reported only once /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each function it appears in.) libtool: link: `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 ----------------------------------------------------------------------------------------------------------------------- Another question I have is, in which folder will the .so files be placed after make finishes? thank you very much for your help. Best Regards Luis From tjarvi at qbang.org Sat May 2 19:27:08 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 19:27:08 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FCC5DA.6000700@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> Message-ID: On Sat, 2 May 2009, Luis Moreira wrote: > Trent Jarvi wrote: >> >> >> On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: >> >>> Hi Travis, >>> The problem with the Makefile is not a problem,When I run ./configure >>> I make a new Makefile with the same data in it, hence what I just >>> modified is removed. >>> The issues I still have is the errors after that. Do you have any >>> idea what can be causing this errors? >>> >>> _______________________________________________________________________________ >>> >>> conftest.c: In function 'main': >>> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >>> function) >>> conftest.c:8: error: (Each undeclared identifier is reported only once >>> conftest.c:8: error: for each function it appears in.) >>> conftest.c:8: error: expected ')' before string constant >>> conftest.c:8: warning: format not a string literal and no format >>> arguments >>> ./configure: line 21462: ./conftest: No such file or directory >>> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >>> expected >>> configure: creating ./config.status >>> config.status: creating Makefile >>> config.status: creating config.h >>> config.status: config.h is unchanged >>> config.status: executing depfiles commands >>> ------------------------------------------------------------------------------- >>> >>> >>> >> >> This was corrected in CVS. I think you can just do the following in >> the top directory: >> >> cvs login: (pw is mousy) >> cvs update >> >> That will get the current fixes. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > apologies for the mix-up of your name. > I managed to get further on by updating CVS, the configure command gets > to the end without any errors, it still warns me that it is confused > about where to find the jni_md.h but I just edited the Makefile and > sorted that out. > I then run make, with no parameters following the instructions on the > Wiki, but that generated a few more errors: > ----------------------------------------------------------------------------------------------------------------------- > > gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. > -I/usr/lib/jvm/java-6-openjdk/include > /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE > -D_BSD_SOURCE -D__need_timespec -c > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o > /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' > undeclared (first use in this function) > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared > identifier is reported only once > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each > function it appears in.) > libtool: link: > `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a > valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 > ----------------------------------------------------------------------------------------------------------------------- > > Another question I have is, in which folder will the .so files be placed > after make finishes? > > thank you very much for your help. > Ah when you do cvs update pass the -Pd option cvs update -Pd Also, when you run configure, use --disable-PRINTER to only build the serial support. It will make things easier. --disable-LOCKFILES will also be easier to get going until you want to learn about how to prevent multiple applications from reading the same serial port. The link for debugging will describe where the files go. By default, it will install in the JRE/JDK under jre/lib/ext (the jar file) jre/lib/i386 (the .so file) Those are on the proper paths when you use the sun or ibm jdk. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sun May 3 01:30:43 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sun, 03 May 2009 08:30:43 +0100 Subject: [Rxtx] First use of RXTX package In-Reply-To: References: <49FCC5DA.6000700@ntlworld.com> Message-ID: <49FD4823.5080204@ntlworld.com> Ah > > when you do cvs update pass the -Pd option > > cvs update -Pd > > Also, when you run configure, use --disable-PRINTER to only build the > serial support. It will make things easier. --disable-LOCKFILES will > also be easier to get going until you want to learn about how to > prevent multiple applications from reading the same serial port. > > The link for debugging will describe where the files go. By default, > it will install in the JRE/JDK under > > jre/lib/ext (the jar file) > jre/lib/i386 (the .so file) > > Those are on the proper paths when you use the sun or ibm jdk. > > http://rxtx.qbang.org/wiki/index.php/Trouble_shooting > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, It as done it! I think this instructions you gave me should be on the Wiki, I can write them for you if you like. Also on the Wiki when you describe the three methods of installing the RxTx package it is confusing because as far as I can see, you always have to do method 1 or the .so files will not be generated(is this correct?). Then you can if you like change the location with method 1 & 2. Is it possible to modify the .la file to point to different directories for installation and then you can decide where to place the files? In a way I have learned quite a lot about Linux by having to struggle, with your help, to find solutions to the problems I encountered (I am still very new to Linux), but maybe we need to log these problems somewhere to make it less of a struggle for others like me. I have used the PortLister example to test it and it came up with my USB to dual Serial adaptor Ports. I will now explore the RxTx package, before I tackle the windows installation, I will let you know of my experience. Thank you for all your Help. Best Regards Luis From tjarvi at qbang.org Sun May 3 10:37:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 3 May 2009 10:37:50 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FD4823.5080204@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> <49FD4823.5080204@ntlworld.com> Message-ID: On Sun, 3 May 2009, Luis Moreira wrote: > Ah >> >> when you do cvs update pass the -Pd option >> >> cvs update -Pd >> >> Also, when you run configure, use --disable-PRINTER to only build the >> serial support. It will make things easier. --disable-LOCKFILES will >> also be easier to get going until you want to learn about how to >> prevent multiple applications from reading the same serial port. >> >> The link for debugging will describe where the files go. By default, >> it will install in the JRE/JDK under >> >> jre/lib/ext (the jar file) >> jre/lib/i386 (the .so file) >> >> Those are on the proper paths when you use the sun or ibm jdk. >> >> http://rxtx.qbang.org/wiki/index.php/Trouble_shooting >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > It as done it! > I think this instructions you gave me should be on the Wiki, I can write > them for you if you like. Also on the Wiki when you describe the three > methods of installing the RxTx package it is confusing because as far > as I can see, you always have to do method 1 or the .so files will not > be generated(is this correct?). Then you can if you like change the > location with method 1 & 2. Is it possible to modify the .la file to > point to different directories for installation and then you can decide > where to place the files? > In a way I have learned quite a lot about Linux by having to struggle, > with your help, to find solutions to the problems I encountered (I am > still very new to Linux), but maybe we need to log these problems > somewhere to make it less of a struggle for others like me. > > I have used the PortLister example to test it and it came up with my USB > to dual Serial adaptor Ports. > > I will now explore the RxTx package, before I tackle the windows > installation, I will let you know of my experience. > > Thank you for all your Help. > Hi Luis, The locations suggested for first time configuration could be documented in a new wiki page explaining that this is not the recommended general workflow but does help new users that are not worried about having rxtx installed into the JRE. For a professional environment, the user would want to follow the workflow currently on the wiki and keep their JRE clean. Often the user will not be able to add libraries to the JRE and will need to use their home directory or a sandbox. Feel free to add information to the wiki. I'd suggest creating comment in the current page and have the comment link to what worked for you as a first time user new to Linux. You can create a new page with your comments. In the long term, we will be working on an autoinstaller that works over the web. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Mon May 4 09:15:40 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Mon, 04 May 2009 16:15:40 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FF069C.8040406@ntlworld.com> Hi Trent, I have now installed the package on my 64 bit machine and when I run my program I get errors on the attachment. I know it as something to do with the architecture of my system but I can no figure out how to fix it. I have built it from source again, I did not transfer the files from machine to machine. can you please put me in the right direction. Thank you very much for your help. Best Regards Luis -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshoot.png Type: image/png Size: 25753 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090504/141ab5dc/attachment-0008.png From johnny.luong at trustcommerce.com Mon May 4 11:57:08 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 04 May 2009 10:57:08 -0700 Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FF069C.8040406@ntlworld.com> References: <49FF069C.8040406@ntlworld.com> Message-ID: <49FF2C74.90805@trustcommerce.com> Luis Moreira wrote: > Hi Trent, > I have now installed the package on my 64 bit machine and when I run my > program I get errors on the attachment. I know it as something to do > with the architecture of my system but I can no figure out how to fix > it. I have built it from source again, I did not transfer the files from > machine to machine. > can you please put me in the right direction. > Thank you very much for your help. > Best Regards > Luis > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Hi, Does running it on a 64-bit JVM help? Your host environment might be building objects for a 64-bit environment unless you did a cross-compile... -- you can find out by doing something like the following: johnny at spike:~$ java -version java version "1.6.0_0" OpenJDK Runtime Environment (build 1.6.0_0-b11) OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode) johnny at spike:~$ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) -Johnny From huangdongkai at gmail.com Wed May 6 11:06:06 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 01:06:06 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. Message-ID: Dear all, I recompile the rxtxSerial source code by MinGW32 and compile success. But when I run my Application which use rxtxSerial.dll to communicate with serial port, a runtime exception happened and application crash. I have no idea why it can not work, beacuse i have not change any source code of rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I have missed when compile the source code on Window NT? Here below is the output error massage. # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, tid=1360 # # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing windows-x86) # Problematic frame: # V [jvm.dll+0x1b6824] # # An error report file with more information is saved as: # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/32c1e699/attachment-0006.html From tjarvi at qbang.org Wed May 6 20:04:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 May 2009 20:04:10 -0600 (MDT) Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: On Thu, 7 May 2009, dongkai huang wrote: > Dear all, > ????? I recompile the rxtxSerial source code by MinGW32 and compile success. > But when I run my Application which use rxtxSerial.dll to communicate with > serial port, a runtime exception happened and application crash.? I have no > idea why it can not work, beacuse i have not change any source code of > rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I > have missed when compile the source code on Window NT? Here below is the > output error massage. > # > # An unexpected error has been detected by Java Runtime Environment: > # > #? EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, > tid=1360 > # > # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing > windows-x86) > > # Problematic frame: > # V? [jvm.dll+0x1b6824] > # > # An error report file with more information is saved as: > # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log > # > # If you would like to submit a bug report, please visit: > #?? http://java.sun.com/webapps/bugreport/crash.jsp > # > > > Hi Dongkai Could you explain how you compiled rxtx with mingw? Did you run configure? Was the compiler native or a cross compiler (like compiling on Linux for Windows)? Is the crash happening when you first open the port or is it happening randomly later on? -- Trent Jarvi tjarvi at qbang.org From huangdongkai at gmail.com Wed May 6 20:48:56 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 10:48:56 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Hi Trent, I was followed the step on INSTALL file, did not run the configure, I used the Makefile.mingw32 which include on the source code package, and only change some path( jdk home path etc.). And I use the native compiler on Windows. The crash happened on I call the getPortIdentifiers() every time. On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Dear all, >> I recompile the rxtxSerial source code by MinGW32 and compile >> success. >> But when I run my Application which use rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and application crash. I have >> no >> idea why it can not work, beacuse i have not change any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing >> I >> have missed when compile the source code on Window NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is saved as: >> # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> > Hi Dongkai > > Could you explain how you compiled rxtx with mingw? Did you run configure? > Was the compiler native or a cross compiler (like compiling on Linux for > Windows)? > > Is the crash happening when you first open the port or is it happening > randomly later on? > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/733eded5/attachment-0006.html From m.j.tandy at warwick.ac.uk Thu May 7 10:39:12 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 7 May 2009 17:39:12 +0100 Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. Message-ID: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> I've encountered a bug in how XON/XOFF are handled on Windows. The symptoms were: 1. XON/XOFF from device to PC did not stop transmission. 2. XON/XOFF characters were present in data read from serial port input stream, when it was expected that they would be stripped out. 3. Investigation with SysInternals PortMon revealed the following configuration when using rxtx: 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 while HyperTerminal, which did not have the same problems as me, produced the following: 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 In other words, the problem is that, in addition to being told to use XON/XOFF flow control, the computer has to explicitly be told which characters to use for 'XON' and 'XOFF'. This part of the configuration was being missed out. I got the latest rxtx source from CVS, and identified the problem as an omission in the 'init_termios' function of 'termios.c', which configures the unix/termios 'c_cc' (control characters) data structure - but omits to configure the VSTART and VSTOP control characters. Later, the termios c_cc data structure is translated (by termios_to_DCB) into a data structure named 'DCB', which is passed to the windows serial port configuration interface. By adding two lines defining the standard XON/XOFF characters to the function init_termios, the bug is fixed. A patch doing this is attached. Thanks, Michael Tandy -------------- next part -------------- A non-text attachment was scrubbed... Name: xon-xoff.diff Type: application/octet-stream Size: 667 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/159c0dcc/attachment-0005.obj From tjarvi at qbang.org Thu May 7 17:57:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 May 2009 17:57:28 -0600 (MDT) Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. In-Reply-To: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> References: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> Message-ID: On Thu, 7 May 2009, Michael Tandy wrote: > I've encountered a bug in how XON/XOFF are handled on Windows. > > The symptoms were: > 1. XON/XOFF from device to PC did not stop transmission. > 2. XON/XOFF characters were present in data read from serial port > input stream, when it was expected that they would be stripped out. > 3. Investigation with SysInternals PortMon revealed the following > configuration when using rxtx: > > 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 > BRK:0 EVT:a XON:0 XOFF:0 > > while HyperTerminal, which did not have the same problems as me, > produced the following: > > 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 > > In other words, the problem is that, in addition to being told to use > XON/XOFF flow control, the computer has to explicitly be told which > characters to use for 'XON' and 'XOFF'. This part of the configuration > was being missed out. > > I got the latest rxtx source from CVS, and identified the problem as > an omission in the 'init_termios' function of 'termios.c', which > configures the unix/termios 'c_cc' (control characters) data structure > - but omits to configure the VSTART and VSTOP control characters. > Later, the termios c_cc data structure is translated (by > termios_to_DCB) into a data structure named 'DCB', which is passed to > the windows serial port configuration interface. > > By adding two lines defining the standard XON/XOFF characters to the > function init_termios, the bug is fixed. A patch doing this is > attached. > Thanks Michael, Good timing. I plan on releasing rxtx-2.2 this coming Sunday. -- Trent Jarvi tjarvi at qbang.org From wjr at weru.ksu.edu Fri May 8 11:38:29 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Fri, 08 May 2009 12:38:29 -0500 Subject: [Rxtx] swing jfilechooser lockup Message-ID: <4A046E15.6010907@weru.ksu.edu> Hi, I wrote a small swing app to download images from an industrial camera. I used the two way serial sample code as a starting point. The app works fine EXCEPT for a call to jfilechooser. After I open the comm port and then try to change the output directory or log file, the jfilechooser winds up trying to unpark (note, parking is not something I'm really familiar with) and doesn't. If I try to change the file or directory before I start the comm port, it works. If I click on menu items that don't call jfilechooser, everything is OK. If I try closing the comm port and then try to create a jfilechooser, it locks up. There is obviously some sort of deadlock here because the awt thread starts waiting on something but it's not clear what. I haven't gone thru the rxtx code yet because it's not in the file structure that netbeans wants for debugging purposes. However, debugging code that I don't have a clear idea of what it is supposed to do is not my idea of a good time. Does anyone have any ideas on what is going on here? Thanks, wjr From Bob_Jacobsen at lbl.gov Fri May 8 14:48:25 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Fri, 8 May 2009 13:48:25 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A046E15.6010907@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> Message-ID: At 12:38 PM -0500 5/8/09, Bill Rust wrote: >Hi, > >I wrote a small swing app to download images from an industrial camera. >I used the two way serial sample code as a starting point. The app works >fine EXCEPT for a call to jfilechooser. After I open the comm port and >then try to change the output directory or log file, the jfilechooser >winds up trying to unpark (note, parking is not something I'm really >familiar with) and doesn't. If I try to change the file or directory >before I start the comm port, it works. If I click on menu items that >don't call jfilechooser, everything is OK. If I try closing the comm >port and then try to create a jfilechooser, it locks up. There is >obviously some sort of deadlock here because the awt thread starts >waiting on something but it's not clear what. I haven't gone thru the >rxtx code yet because it's not in the file structure that netbeans wants >for debugging purposes. However, debugging code that I don't have a >clear idea of what it is supposed to do is not my idea of a good time. What is the threading structure of your code? The various high-function Swing components, such as JFileChooser, are notorious for doing Really Bad Stuff when invoked from off the Swing thread. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From bschlining at gmail.com Fri May 8 15:08:50 2009 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 8 May 2009 14:08:50 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: Bob's probably right...take look at javax.swing.SwingUtilites for the workaround to get your swing stuff invoked on the EventDispatchThread (EDT). Some swing-methods do work when called outside of the EDT, but just to be safe, do your creation and swing calls on the EDT. It's really simple, here's an example of a synchronous call. // Here's how to run stuff on the EDT from a different thread SwingUtilities.invokeAndWait(new Runnable() { public void run() { JFileChooser fc; // create, setup, show your filechooser // Get the result from the filechooser } }); To do a asynchronous call use SwingUtilities.invokeLater > >I wrote a small swing app to download images from an industrial camera. > >I used the two way serial sample code as a starting point. The app works > >fine EXCEPT for a call to jfilechooser. After I open the comm port and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090508/c21c2127/attachment-0004.html From tod at todbot.com Fri May 8 16:27:12 2009 From: tod at todbot.com (Tod E. Kurt) Date: Fri, 8 May 2009 15:27:12 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> This is the exact technique I use to let the user choose which serial port to use on startup. Here's a method I've got in many of my sketches: void choosePort() { String portlist[] = Serial.list(); String port = null; javax.swing.SwingUtilities.invokeLater(new Runnable() { public void run() { try { String port = (String) javax.swing.JOptionPane.showInputDialog( null, "Select Serial Port", "MySuperSketch", javax.swing.JOptionPane.QUESTION_MESSAGE, null, portlist, null); if( port == null ) { javax.swing.JOptionPane.showMessageDialog(null, "No port chosen, goodbye"); System.exit(1); } serialPort = port; } catch (Exception e) { e.printStackTrace(); } } } ); } On May 8, 2009, at 2:08 p, Brian Schlining wrote: > Bob's probably right...take look at javax.swing.SwingUtilites for > the workaround to get your swing stuff invoked on the > EventDispatchThread (EDT). Some swing-methods do work when called > outside of the EDT, but just to be safe, do your creation and swing > calls on the EDT. It's really simple, here's an example of a > synchronous call. > > // Here's how to run stuff on the EDT from a different thread > SwingUtilities.invokeAndWait(new Runnable() { > public void run() { > JFileChooser fc; // create, setup, show your filechooser > // Get the result from the filechooser > } > }); > > To do a asynchronous call use SwingUtilities.invokeLater > > > >I wrote a small swing app to download images from an industrial > camera. > >I used the two way serial sample code as a starting point. The app > works > >fine EXCEPT for a call to jfilechooser. After I open the comm port > and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From huangdongkai at gmail.com Sat May 9 04:46:22 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Sat, 9 May 2009 18:46:22 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Dear Trent, After I intsall the ming32-cross compile to compile the rxtxSerial.dll and testing, i found the same problem still exist. I am not sure my compiler version is the same as your's. Could you tell me the way you can success compile rxtx-2.1-7r2 release source code? Thanks for you kindly help. On Fri, May 8, 2009 at 8:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Hi Trent, >> The attach is the Make file I use to compile the rxtx. >> >> On Thu, May 7, 2009 at 10:48 AM, dongkai huang >> wrote: >> Hi Trent, >> I was followed the step on INSTALL file, did not run the >> configure, I used the Makefile.mingw32 which include on the >> source code package, and only change some path( jdk home path >> etc.). And I use the native compiler on Windows. >> The crash happened on I call the getPortIdentifiers() >> every time. >> >> On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: >> >> >> On Thu, 7 May 2009, dongkai huang wrote: >> >> Dear all, >> I recompile the rxtxSerial source code by >> MinGW32 and compile success. >> But when I run my Application which use >> rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and >> application crash. I have no >> idea why it can not work, beacuse i have not change >> any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source >> code. Did some thing I >> have missed when compile the source code on Window >> NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java >> Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at >> pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 >> mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is >> saved as: >> # >> D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please >> visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> >> Hi Dongkai >> >> Could you explain how you compiled rxtx with mingw? Did you run >> configure? Was the compiler native or a cross compiler (like >> compiling on Linux for Windows)? >> >> Is the crash happening when you first open the port or is it >> happening randomly later on? >> >> > Thanks Dongkai > > I'll look at your Makefile tomorrow. Which version of mingw was this? > > I suspect there is a problem with that makefile. I usually built that > version of rxtx for windows with a mingw32 cross compiler using the > configure script. > > The configure script may well work for you if you have a cygwin environment > with mingw instead of gcc. I'll take a look at what is different. > > -- > > Trent Jarvi > tjarvi at qbang.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090509/b729c429/attachment-0003.html From luis.moreira at ntlworld.com Sat May 2 00:39:04 2009 From: luis.moreira at ntlworld.com (luis.moreira at ntlworld.com) Date: Sat, 2 May 2009 7:39:04 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Hi Travis, The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. The issues I still have is the errors after that. Do you have any idea what can be causing this errors? _______________________________________________________________________________ conftest.c: In function 'main': conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) conftest.c:8: error: (Each undeclared identifier is reported only once conftest.c:8: error: for each function it appears in.) conftest.c:8: error: expected ')' before string constant conftest.c:8: warning: format not a string literal and no format arguments ./configure: line 21462: ./conftest: No such file or directory ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands ------------------------------------------------------------------------------- I don't know what happened to my previous post, it as not showed up in the list. Best Regards Luis From tjarvi at qbang.org Sat May 2 07:30:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 07:30:04 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> References: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Message-ID: On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > Hi Travis, > The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. > The issues I still have is the errors after that. Do you have any idea what can be causing this errors? > > _______________________________________________________________________________ > conftest.c: In function 'main': > conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) > conftest.c:8: error: (Each undeclared identifier is reported only once > conftest.c:8: error: for each function it appears in.) > conftest.c:8: error: expected ')' before string constant > conftest.c:8: warning: format not a string literal and no format arguments > ./configure: line 21462: ./conftest: No such file or directory > ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: config.h is unchanged > config.status: executing depfiles commands > ------------------------------------------------------------------------------- > > This was corrected in CVS. I think you can just do the following in the top directory: cvs login: (pw is mousy) cvs update That will get the current fixes. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sat May 2 16:14:50 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sat, 02 May 2009 23:14:50 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FCC5DA.6000700@ntlworld.com> Trent Jarvi wrote: > > > On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > >> Hi Travis, >> The problem with the Makefile is not a problem,When I run ./configure >> I make a new Makefile with the same data in it, hence what I just >> modified is removed. >> The issues I still have is the errors after that. Do you have any >> idea what can be causing this errors? >> >> _______________________________________________________________________________ >> >> conftest.c: In function 'main': >> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >> function) >> conftest.c:8: error: (Each undeclared identifier is reported only once >> conftest.c:8: error: for each function it appears in.) >> conftest.c:8: error: expected ')' before string constant >> conftest.c:8: warning: format not a string literal and no format >> arguments >> ./configure: line 21462: ./conftest: No such file or directory >> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >> expected >> configure: creating ./config.status >> config.status: creating Makefile >> config.status: creating config.h >> config.status: config.h is unchanged >> config.status: executing depfiles commands >> ------------------------------------------------------------------------------- >> >> >> > > This was corrected in CVS. I think you can just do the following in > the top directory: > > cvs login: (pw is mousy) > cvs update > > That will get the current fixes. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, apologies for the mix-up of your name. I managed to get further on by updating CVS, the configure command gets to the end without any errors, it still warns me that it is confused about where to find the jni_md.h but I just edited the Makefile and sorted that out. I then run make, with no parameters following the instructions on the Wiki, but that generated a few more errors: ----------------------------------------------------------------------------------------------------------------------- gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. -I/usr/lib/jvm/java-6-openjdk/include /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' undeclared (first use in this function) /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared identifier is reported only once /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each function it appears in.) libtool: link: `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 ----------------------------------------------------------------------------------------------------------------------- Another question I have is, in which folder will the .so files be placed after make finishes? thank you very much for your help. Best Regards Luis From tjarvi at qbang.org Sat May 2 19:27:08 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 19:27:08 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FCC5DA.6000700@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> Message-ID: On Sat, 2 May 2009, Luis Moreira wrote: > Trent Jarvi wrote: >> >> >> On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: >> >>> Hi Travis, >>> The problem with the Makefile is not a problem,When I run ./configure >>> I make a new Makefile with the same data in it, hence what I just >>> modified is removed. >>> The issues I still have is the errors after that. Do you have any >>> idea what can be causing this errors? >>> >>> _______________________________________________________________________________ >>> >>> conftest.c: In function 'main': >>> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >>> function) >>> conftest.c:8: error: (Each undeclared identifier is reported only once >>> conftest.c:8: error: for each function it appears in.) >>> conftest.c:8: error: expected ')' before string constant >>> conftest.c:8: warning: format not a string literal and no format >>> arguments >>> ./configure: line 21462: ./conftest: No such file or directory >>> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >>> expected >>> configure: creating ./config.status >>> config.status: creating Makefile >>> config.status: creating config.h >>> config.status: config.h is unchanged >>> config.status: executing depfiles commands >>> ------------------------------------------------------------------------------- >>> >>> >>> >> >> This was corrected in CVS. I think you can just do the following in >> the top directory: >> >> cvs login: (pw is mousy) >> cvs update >> >> That will get the current fixes. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > apologies for the mix-up of your name. > I managed to get further on by updating CVS, the configure command gets > to the end without any errors, it still warns me that it is confused > about where to find the jni_md.h but I just edited the Makefile and > sorted that out. > I then run make, with no parameters following the instructions on the > Wiki, but that generated a few more errors: > ----------------------------------------------------------------------------------------------------------------------- > > gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. > -I/usr/lib/jvm/java-6-openjdk/include > /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE > -D_BSD_SOURCE -D__need_timespec -c > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o > /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' > undeclared (first use in this function) > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared > identifier is reported only once > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each > function it appears in.) > libtool: link: > `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a > valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 > ----------------------------------------------------------------------------------------------------------------------- > > Another question I have is, in which folder will the .so files be placed > after make finishes? > > thank you very much for your help. > Ah when you do cvs update pass the -Pd option cvs update -Pd Also, when you run configure, use --disable-PRINTER to only build the serial support. It will make things easier. --disable-LOCKFILES will also be easier to get going until you want to learn about how to prevent multiple applications from reading the same serial port. The link for debugging will describe where the files go. By default, it will install in the JRE/JDK under jre/lib/ext (the jar file) jre/lib/i386 (the .so file) Those are on the proper paths when you use the sun or ibm jdk. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sun May 3 01:30:43 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sun, 03 May 2009 08:30:43 +0100 Subject: [Rxtx] First use of RXTX package In-Reply-To: References: <49FCC5DA.6000700@ntlworld.com> Message-ID: <49FD4823.5080204@ntlworld.com> Ah > > when you do cvs update pass the -Pd option > > cvs update -Pd > > Also, when you run configure, use --disable-PRINTER to only build the > serial support. It will make things easier. --disable-LOCKFILES will > also be easier to get going until you want to learn about how to > prevent multiple applications from reading the same serial port. > > The link for debugging will describe where the files go. By default, > it will install in the JRE/JDK under > > jre/lib/ext (the jar file) > jre/lib/i386 (the .so file) > > Those are on the proper paths when you use the sun or ibm jdk. > > http://rxtx.qbang.org/wiki/index.php/Trouble_shooting > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, It as done it! I think this instructions you gave me should be on the Wiki, I can write them for you if you like. Also on the Wiki when you describe the three methods of installing the RxTx package it is confusing because as far as I can see, you always have to do method 1 or the .so files will not be generated(is this correct?). Then you can if you like change the location with method 1 & 2. Is it possible to modify the .la file to point to different directories for installation and then you can decide where to place the files? In a way I have learned quite a lot about Linux by having to struggle, with your help, to find solutions to the problems I encountered (I am still very new to Linux), but maybe we need to log these problems somewhere to make it less of a struggle for others like me. I have used the PortLister example to test it and it came up with my USB to dual Serial adaptor Ports. I will now explore the RxTx package, before I tackle the windows installation, I will let you know of my experience. Thank you for all your Help. Best Regards Luis From tjarvi at qbang.org Sun May 3 10:37:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 3 May 2009 10:37:50 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FD4823.5080204@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> <49FD4823.5080204@ntlworld.com> Message-ID: On Sun, 3 May 2009, Luis Moreira wrote: > Ah >> >> when you do cvs update pass the -Pd option >> >> cvs update -Pd >> >> Also, when you run configure, use --disable-PRINTER to only build the >> serial support. It will make things easier. --disable-LOCKFILES will >> also be easier to get going until you want to learn about how to >> prevent multiple applications from reading the same serial port. >> >> The link for debugging will describe where the files go. By default, >> it will install in the JRE/JDK under >> >> jre/lib/ext (the jar file) >> jre/lib/i386 (the .so file) >> >> Those are on the proper paths when you use the sun or ibm jdk. >> >> http://rxtx.qbang.org/wiki/index.php/Trouble_shooting >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > It as done it! > I think this instructions you gave me should be on the Wiki, I can write > them for you if you like. Also on the Wiki when you describe the three > methods of installing the RxTx package it is confusing because as far > as I can see, you always have to do method 1 or the .so files will not > be generated(is this correct?). Then you can if you like change the > location with method 1 & 2. Is it possible to modify the .la file to > point to different directories for installation and then you can decide > where to place the files? > In a way I have learned quite a lot about Linux by having to struggle, > with your help, to find solutions to the problems I encountered (I am > still very new to Linux), but maybe we need to log these problems > somewhere to make it less of a struggle for others like me. > > I have used the PortLister example to test it and it came up with my USB > to dual Serial adaptor Ports. > > I will now explore the RxTx package, before I tackle the windows > installation, I will let you know of my experience. > > Thank you for all your Help. > Hi Luis, The locations suggested for first time configuration could be documented in a new wiki page explaining that this is not the recommended general workflow but does help new users that are not worried about having rxtx installed into the JRE. For a professional environment, the user would want to follow the workflow currently on the wiki and keep their JRE clean. Often the user will not be able to add libraries to the JRE and will need to use their home directory or a sandbox. Feel free to add information to the wiki. I'd suggest creating comment in the current page and have the comment link to what worked for you as a first time user new to Linux. You can create a new page with your comments. In the long term, we will be working on an autoinstaller that works over the web. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Mon May 4 09:15:40 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Mon, 04 May 2009 16:15:40 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FF069C.8040406@ntlworld.com> Hi Trent, I have now installed the package on my 64 bit machine and when I run my program I get errors on the attachment. I know it as something to do with the architecture of my system but I can no figure out how to fix it. I have built it from source again, I did not transfer the files from machine to machine. can you please put me in the right direction. Thank you very much for your help. Best Regards Luis -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshoot.png Type: image/png Size: 25753 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090504/141ab5dc/attachment-0009.png From johnny.luong at trustcommerce.com Mon May 4 11:57:08 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 04 May 2009 10:57:08 -0700 Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FF069C.8040406@ntlworld.com> References: <49FF069C.8040406@ntlworld.com> Message-ID: <49FF2C74.90805@trustcommerce.com> Luis Moreira wrote: > Hi Trent, > I have now installed the package on my 64 bit machine and when I run my > program I get errors on the attachment. I know it as something to do > with the architecture of my system but I can no figure out how to fix > it. I have built it from source again, I did not transfer the files from > machine to machine. > can you please put me in the right direction. > Thank you very much for your help. > Best Regards > Luis > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Hi, Does running it on a 64-bit JVM help? Your host environment might be building objects for a 64-bit environment unless you did a cross-compile... -- you can find out by doing something like the following: johnny at spike:~$ java -version java version "1.6.0_0" OpenJDK Runtime Environment (build 1.6.0_0-b11) OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode) johnny at spike:~$ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) -Johnny From huangdongkai at gmail.com Wed May 6 11:06:06 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 01:06:06 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. Message-ID: Dear all, I recompile the rxtxSerial source code by MinGW32 and compile success. But when I run my Application which use rxtxSerial.dll to communicate with serial port, a runtime exception happened and application crash. I have no idea why it can not work, beacuse i have not change any source code of rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I have missed when compile the source code on Window NT? Here below is the output error massage. # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, tid=1360 # # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing windows-x86) # Problematic frame: # V [jvm.dll+0x1b6824] # # An error report file with more information is saved as: # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/32c1e699/attachment-0007.html From tjarvi at qbang.org Wed May 6 20:04:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 May 2009 20:04:10 -0600 (MDT) Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: On Thu, 7 May 2009, dongkai huang wrote: > Dear all, > ????? I recompile the rxtxSerial source code by MinGW32 and compile success. > But when I run my Application which use rxtxSerial.dll to communicate with > serial port, a runtime exception happened and application crash.? I have no > idea why it can not work, beacuse i have not change any source code of > rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I > have missed when compile the source code on Window NT? Here below is the > output error massage. > # > # An unexpected error has been detected by Java Runtime Environment: > # > #? EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, > tid=1360 > # > # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing > windows-x86) > > # Problematic frame: > # V? [jvm.dll+0x1b6824] > # > # An error report file with more information is saved as: > # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log > # > # If you would like to submit a bug report, please visit: > #?? http://java.sun.com/webapps/bugreport/crash.jsp > # > > > Hi Dongkai Could you explain how you compiled rxtx with mingw? Did you run configure? Was the compiler native or a cross compiler (like compiling on Linux for Windows)? Is the crash happening when you first open the port or is it happening randomly later on? -- Trent Jarvi tjarvi at qbang.org From huangdongkai at gmail.com Wed May 6 20:48:56 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 10:48:56 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Hi Trent, I was followed the step on INSTALL file, did not run the configure, I used the Makefile.mingw32 which include on the source code package, and only change some path( jdk home path etc.). And I use the native compiler on Windows. The crash happened on I call the getPortIdentifiers() every time. On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Dear all, >> I recompile the rxtxSerial source code by MinGW32 and compile >> success. >> But when I run my Application which use rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and application crash. I have >> no >> idea why it can not work, beacuse i have not change any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing >> I >> have missed when compile the source code on Window NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is saved as: >> # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> > Hi Dongkai > > Could you explain how you compiled rxtx with mingw? Did you run configure? > Was the compiler native or a cross compiler (like compiling on Linux for > Windows)? > > Is the crash happening when you first open the port or is it happening > randomly later on? > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/733eded5/attachment-0007.html From m.j.tandy at warwick.ac.uk Thu May 7 10:39:12 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 7 May 2009 17:39:12 +0100 Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. Message-ID: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> I've encountered a bug in how XON/XOFF are handled on Windows. The symptoms were: 1. XON/XOFF from device to PC did not stop transmission. 2. XON/XOFF characters were present in data read from serial port input stream, when it was expected that they would be stripped out. 3. Investigation with SysInternals PortMon revealed the following configuration when using rxtx: 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 while HyperTerminal, which did not have the same problems as me, produced the following: 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 In other words, the problem is that, in addition to being told to use XON/XOFF flow control, the computer has to explicitly be told which characters to use for 'XON' and 'XOFF'. This part of the configuration was being missed out. I got the latest rxtx source from CVS, and identified the problem as an omission in the 'init_termios' function of 'termios.c', which configures the unix/termios 'c_cc' (control characters) data structure - but omits to configure the VSTART and VSTOP control characters. Later, the termios c_cc data structure is translated (by termios_to_DCB) into a data structure named 'DCB', which is passed to the windows serial port configuration interface. By adding two lines defining the standard XON/XOFF characters to the function init_termios, the bug is fixed. A patch doing this is attached. Thanks, Michael Tandy -------------- next part -------------- A non-text attachment was scrubbed... Name: xon-xoff.diff Type: application/octet-stream Size: 667 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/159c0dcc/attachment-0006.obj From tjarvi at qbang.org Thu May 7 17:57:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 May 2009 17:57:28 -0600 (MDT) Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. In-Reply-To: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> References: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> Message-ID: On Thu, 7 May 2009, Michael Tandy wrote: > I've encountered a bug in how XON/XOFF are handled on Windows. > > The symptoms were: > 1. XON/XOFF from device to PC did not stop transmission. > 2. XON/XOFF characters were present in data read from serial port > input stream, when it was expected that they would be stripped out. > 3. Investigation with SysInternals PortMon revealed the following > configuration when using rxtx: > > 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 > BRK:0 EVT:a XON:0 XOFF:0 > > while HyperTerminal, which did not have the same problems as me, > produced the following: > > 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 > > In other words, the problem is that, in addition to being told to use > XON/XOFF flow control, the computer has to explicitly be told which > characters to use for 'XON' and 'XOFF'. This part of the configuration > was being missed out. > > I got the latest rxtx source from CVS, and identified the problem as > an omission in the 'init_termios' function of 'termios.c', which > configures the unix/termios 'c_cc' (control characters) data structure > - but omits to configure the VSTART and VSTOP control characters. > Later, the termios c_cc data structure is translated (by > termios_to_DCB) into a data structure named 'DCB', which is passed to > the windows serial port configuration interface. > > By adding two lines defining the standard XON/XOFF characters to the > function init_termios, the bug is fixed. A patch doing this is > attached. > Thanks Michael, Good timing. I plan on releasing rxtx-2.2 this coming Sunday. -- Trent Jarvi tjarvi at qbang.org From wjr at weru.ksu.edu Fri May 8 11:38:29 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Fri, 08 May 2009 12:38:29 -0500 Subject: [Rxtx] swing jfilechooser lockup Message-ID: <4A046E15.6010907@weru.ksu.edu> Hi, I wrote a small swing app to download images from an industrial camera. I used the two way serial sample code as a starting point. The app works fine EXCEPT for a call to jfilechooser. After I open the comm port and then try to change the output directory or log file, the jfilechooser winds up trying to unpark (note, parking is not something I'm really familiar with) and doesn't. If I try to change the file or directory before I start the comm port, it works. If I click on menu items that don't call jfilechooser, everything is OK. If I try closing the comm port and then try to create a jfilechooser, it locks up. There is obviously some sort of deadlock here because the awt thread starts waiting on something but it's not clear what. I haven't gone thru the rxtx code yet because it's not in the file structure that netbeans wants for debugging purposes. However, debugging code that I don't have a clear idea of what it is supposed to do is not my idea of a good time. Does anyone have any ideas on what is going on here? Thanks, wjr From Bob_Jacobsen at lbl.gov Fri May 8 14:48:25 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Fri, 8 May 2009 13:48:25 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A046E15.6010907@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> Message-ID: At 12:38 PM -0500 5/8/09, Bill Rust wrote: >Hi, > >I wrote a small swing app to download images from an industrial camera. >I used the two way serial sample code as a starting point. The app works >fine EXCEPT for a call to jfilechooser. After I open the comm port and >then try to change the output directory or log file, the jfilechooser >winds up trying to unpark (note, parking is not something I'm really >familiar with) and doesn't. If I try to change the file or directory >before I start the comm port, it works. If I click on menu items that >don't call jfilechooser, everything is OK. If I try closing the comm >port and then try to create a jfilechooser, it locks up. There is >obviously some sort of deadlock here because the awt thread starts >waiting on something but it's not clear what. I haven't gone thru the >rxtx code yet because it's not in the file structure that netbeans wants >for debugging purposes. However, debugging code that I don't have a >clear idea of what it is supposed to do is not my idea of a good time. What is the threading structure of your code? The various high-function Swing components, such as JFileChooser, are notorious for doing Really Bad Stuff when invoked from off the Swing thread. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From bschlining at gmail.com Fri May 8 15:08:50 2009 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 8 May 2009 14:08:50 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: Bob's probably right...take look at javax.swing.SwingUtilites for the workaround to get your swing stuff invoked on the EventDispatchThread (EDT). Some swing-methods do work when called outside of the EDT, but just to be safe, do your creation and swing calls on the EDT. It's really simple, here's an example of a synchronous call. // Here's how to run stuff on the EDT from a different thread SwingUtilities.invokeAndWait(new Runnable() { public void run() { JFileChooser fc; // create, setup, show your filechooser // Get the result from the filechooser } }); To do a asynchronous call use SwingUtilities.invokeLater > >I wrote a small swing app to download images from an industrial camera. > >I used the two way serial sample code as a starting point. The app works > >fine EXCEPT for a call to jfilechooser. After I open the comm port and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090508/c21c2127/attachment-0005.html From tod at todbot.com Fri May 8 16:27:12 2009 From: tod at todbot.com (Tod E. Kurt) Date: Fri, 8 May 2009 15:27:12 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> This is the exact technique I use to let the user choose which serial port to use on startup. Here's a method I've got in many of my sketches: void choosePort() { String portlist[] = Serial.list(); String port = null; javax.swing.SwingUtilities.invokeLater(new Runnable() { public void run() { try { String port = (String) javax.swing.JOptionPane.showInputDialog( null, "Select Serial Port", "MySuperSketch", javax.swing.JOptionPane.QUESTION_MESSAGE, null, portlist, null); if( port == null ) { javax.swing.JOptionPane.showMessageDialog(null, "No port chosen, goodbye"); System.exit(1); } serialPort = port; } catch (Exception e) { e.printStackTrace(); } } } ); } On May 8, 2009, at 2:08 p, Brian Schlining wrote: > Bob's probably right...take look at javax.swing.SwingUtilites for > the workaround to get your swing stuff invoked on the > EventDispatchThread (EDT). Some swing-methods do work when called > outside of the EDT, but just to be safe, do your creation and swing > calls on the EDT. It's really simple, here's an example of a > synchronous call. > > // Here's how to run stuff on the EDT from a different thread > SwingUtilities.invokeAndWait(new Runnable() { > public void run() { > JFileChooser fc; // create, setup, show your filechooser > // Get the result from the filechooser > } > }); > > To do a asynchronous call use SwingUtilities.invokeLater > > > >I wrote a small swing app to download images from an industrial > camera. > >I used the two way serial sample code as a starting point. The app > works > >fine EXCEPT for a call to jfilechooser. After I open the comm port > and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From huangdongkai at gmail.com Sat May 9 04:46:22 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Sat, 9 May 2009 18:46:22 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Dear Trent, After I intsall the ming32-cross compile to compile the rxtxSerial.dll and testing, i found the same problem still exist. I am not sure my compiler version is the same as your's. Could you tell me the way you can success compile rxtx-2.1-7r2 release source code? Thanks for you kindly help. On Fri, May 8, 2009 at 8:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Hi Trent, >> The attach is the Make file I use to compile the rxtx. >> >> On Thu, May 7, 2009 at 10:48 AM, dongkai huang >> wrote: >> Hi Trent, >> I was followed the step on INSTALL file, did not run the >> configure, I used the Makefile.mingw32 which include on the >> source code package, and only change some path( jdk home path >> etc.). And I use the native compiler on Windows. >> The crash happened on I call the getPortIdentifiers() >> every time. >> >> On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: >> >> >> On Thu, 7 May 2009, dongkai huang wrote: >> >> Dear all, >> I recompile the rxtxSerial source code by >> MinGW32 and compile success. >> But when I run my Application which use >> rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and >> application crash. I have no >> idea why it can not work, beacuse i have not change >> any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source >> code. Did some thing I >> have missed when compile the source code on Window >> NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java >> Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at >> pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 >> mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is >> saved as: >> # >> D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please >> visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> >> Hi Dongkai >> >> Could you explain how you compiled rxtx with mingw? Did you run >> configure? Was the compiler native or a cross compiler (like >> compiling on Linux for Windows)? >> >> Is the crash happening when you first open the port or is it >> happening randomly later on? >> >> > Thanks Dongkai > > I'll look at your Makefile tomorrow. Which version of mingw was this? > > I suspect there is a problem with that makefile. I usually built that > version of rxtx for windows with a mingw32 cross compiler using the > configure script. > > The configure script may well work for you if you have a cygwin environment > with mingw instead of gcc. I'll take a look at what is different. > > -- > > Trent Jarvi > tjarvi at qbang.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090509/b729c429/attachment-0004.html From luis.moreira at ntlworld.com Sat May 2 00:39:04 2009 From: luis.moreira at ntlworld.com (luis.moreira at ntlworld.com) Date: Sat, 2 May 2009 7:39:04 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Hi Travis, The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. The issues I still have is the errors after that. Do you have any idea what can be causing this errors? _______________________________________________________________________________ conftest.c: In function 'main': conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) conftest.c:8: error: (Each undeclared identifier is reported only once conftest.c:8: error: for each function it appears in.) conftest.c:8: error: expected ')' before string constant conftest.c:8: warning: format not a string literal and no format arguments ./configure: line 21462: ./conftest: No such file or directory ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands ------------------------------------------------------------------------------- I don't know what happened to my previous post, it as not showed up in the list. Best Regards Luis From tjarvi at qbang.org Sat May 2 07:30:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 07:30:04 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> References: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Message-ID: On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > Hi Travis, > The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. > The issues I still have is the errors after that. Do you have any idea what can be causing this errors? > > _______________________________________________________________________________ > conftest.c: In function 'main': > conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) > conftest.c:8: error: (Each undeclared identifier is reported only once > conftest.c:8: error: for each function it appears in.) > conftest.c:8: error: expected ')' before string constant > conftest.c:8: warning: format not a string literal and no format arguments > ./configure: line 21462: ./conftest: No such file or directory > ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: config.h is unchanged > config.status: executing depfiles commands > ------------------------------------------------------------------------------- > > This was corrected in CVS. I think you can just do the following in the top directory: cvs login: (pw is mousy) cvs update That will get the current fixes. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sat May 2 16:14:50 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sat, 02 May 2009 23:14:50 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FCC5DA.6000700@ntlworld.com> Trent Jarvi wrote: > > > On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > >> Hi Travis, >> The problem with the Makefile is not a problem,When I run ./configure >> I make a new Makefile with the same data in it, hence what I just >> modified is removed. >> The issues I still have is the errors after that. Do you have any >> idea what can be causing this errors? >> >> _______________________________________________________________________________ >> >> conftest.c: In function 'main': >> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >> function) >> conftest.c:8: error: (Each undeclared identifier is reported only once >> conftest.c:8: error: for each function it appears in.) >> conftest.c:8: error: expected ')' before string constant >> conftest.c:8: warning: format not a string literal and no format >> arguments >> ./configure: line 21462: ./conftest: No such file or directory >> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >> expected >> configure: creating ./config.status >> config.status: creating Makefile >> config.status: creating config.h >> config.status: config.h is unchanged >> config.status: executing depfiles commands >> ------------------------------------------------------------------------------- >> >> >> > > This was corrected in CVS. I think you can just do the following in > the top directory: > > cvs login: (pw is mousy) > cvs update > > That will get the current fixes. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, apologies for the mix-up of your name. I managed to get further on by updating CVS, the configure command gets to the end without any errors, it still warns me that it is confused about where to find the jni_md.h but I just edited the Makefile and sorted that out. I then run make, with no parameters following the instructions on the Wiki, but that generated a few more errors: ----------------------------------------------------------------------------------------------------------------------- gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. -I/usr/lib/jvm/java-6-openjdk/include /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' undeclared (first use in this function) /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared identifier is reported only once /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each function it appears in.) libtool: link: `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 ----------------------------------------------------------------------------------------------------------------------- Another question I have is, in which folder will the .so files be placed after make finishes? thank you very much for your help. Best Regards Luis From tjarvi at qbang.org Sat May 2 19:27:08 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 19:27:08 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FCC5DA.6000700@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> Message-ID: On Sat, 2 May 2009, Luis Moreira wrote: > Trent Jarvi wrote: >> >> >> On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: >> >>> Hi Travis, >>> The problem with the Makefile is not a problem,When I run ./configure >>> I make a new Makefile with the same data in it, hence what I just >>> modified is removed. >>> The issues I still have is the errors after that. Do you have any >>> idea what can be causing this errors? >>> >>> _______________________________________________________________________________ >>> >>> conftest.c: In function 'main': >>> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >>> function) >>> conftest.c:8: error: (Each undeclared identifier is reported only once >>> conftest.c:8: error: for each function it appears in.) >>> conftest.c:8: error: expected ')' before string constant >>> conftest.c:8: warning: format not a string literal and no format >>> arguments >>> ./configure: line 21462: ./conftest: No such file or directory >>> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >>> expected >>> configure: creating ./config.status >>> config.status: creating Makefile >>> config.status: creating config.h >>> config.status: config.h is unchanged >>> config.status: executing depfiles commands >>> ------------------------------------------------------------------------------- >>> >>> >>> >> >> This was corrected in CVS. I think you can just do the following in >> the top directory: >> >> cvs login: (pw is mousy) >> cvs update >> >> That will get the current fixes. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > apologies for the mix-up of your name. > I managed to get further on by updating CVS, the configure command gets > to the end without any errors, it still warns me that it is confused > about where to find the jni_md.h but I just edited the Makefile and > sorted that out. > I then run make, with no parameters following the instructions on the > Wiki, but that generated a few more errors: > ----------------------------------------------------------------------------------------------------------------------- > > gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. > -I/usr/lib/jvm/java-6-openjdk/include > /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE > -D_BSD_SOURCE -D__need_timespec -c > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o > /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' > undeclared (first use in this function) > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared > identifier is reported only once > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each > function it appears in.) > libtool: link: > `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a > valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 > ----------------------------------------------------------------------------------------------------------------------- > > Another question I have is, in which folder will the .so files be placed > after make finishes? > > thank you very much for your help. > Ah when you do cvs update pass the -Pd option cvs update -Pd Also, when you run configure, use --disable-PRINTER to only build the serial support. It will make things easier. --disable-LOCKFILES will also be easier to get going until you want to learn about how to prevent multiple applications from reading the same serial port. The link for debugging will describe where the files go. By default, it will install in the JRE/JDK under jre/lib/ext (the jar file) jre/lib/i386 (the .so file) Those are on the proper paths when you use the sun or ibm jdk. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sun May 3 01:30:43 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sun, 03 May 2009 08:30:43 +0100 Subject: [Rxtx] First use of RXTX package In-Reply-To: References: <49FCC5DA.6000700@ntlworld.com> Message-ID: <49FD4823.5080204@ntlworld.com> Ah > > when you do cvs update pass the -Pd option > > cvs update -Pd > > Also, when you run configure, use --disable-PRINTER to only build the > serial support. It will make things easier. --disable-LOCKFILES will > also be easier to get going until you want to learn about how to > prevent multiple applications from reading the same serial port. > > The link for debugging will describe where the files go. By default, > it will install in the JRE/JDK under > > jre/lib/ext (the jar file) > jre/lib/i386 (the .so file) > > Those are on the proper paths when you use the sun or ibm jdk. > > http://rxtx.qbang.org/wiki/index.php/Trouble_shooting > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, It as done it! I think this instructions you gave me should be on the Wiki, I can write them for you if you like. Also on the Wiki when you describe the three methods of installing the RxTx package it is confusing because as far as I can see, you always have to do method 1 or the .so files will not be generated(is this correct?). Then you can if you like change the location with method 1 & 2. Is it possible to modify the .la file to point to different directories for installation and then you can decide where to place the files? In a way I have learned quite a lot about Linux by having to struggle, with your help, to find solutions to the problems I encountered (I am still very new to Linux), but maybe we need to log these problems somewhere to make it less of a struggle for others like me. I have used the PortLister example to test it and it came up with my USB to dual Serial adaptor Ports. I will now explore the RxTx package, before I tackle the windows installation, I will let you know of my experience. Thank you for all your Help. Best Regards Luis From tjarvi at qbang.org Sun May 3 10:37:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 3 May 2009 10:37:50 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FD4823.5080204@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> <49FD4823.5080204@ntlworld.com> Message-ID: On Sun, 3 May 2009, Luis Moreira wrote: > Ah >> >> when you do cvs update pass the -Pd option >> >> cvs update -Pd >> >> Also, when you run configure, use --disable-PRINTER to only build the >> serial support. It will make things easier. --disable-LOCKFILES will >> also be easier to get going until you want to learn about how to >> prevent multiple applications from reading the same serial port. >> >> The link for debugging will describe where the files go. By default, >> it will install in the JRE/JDK under >> >> jre/lib/ext (the jar file) >> jre/lib/i386 (the .so file) >> >> Those are on the proper paths when you use the sun or ibm jdk. >> >> http://rxtx.qbang.org/wiki/index.php/Trouble_shooting >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > It as done it! > I think this instructions you gave me should be on the Wiki, I can write > them for you if you like. Also on the Wiki when you describe the three > methods of installing the RxTx package it is confusing because as far > as I can see, you always have to do method 1 or the .so files will not > be generated(is this correct?). Then you can if you like change the > location with method 1 & 2. Is it possible to modify the .la file to > point to different directories for installation and then you can decide > where to place the files? > In a way I have learned quite a lot about Linux by having to struggle, > with your help, to find solutions to the problems I encountered (I am > still very new to Linux), but maybe we need to log these problems > somewhere to make it less of a struggle for others like me. > > I have used the PortLister example to test it and it came up with my USB > to dual Serial adaptor Ports. > > I will now explore the RxTx package, before I tackle the windows > installation, I will let you know of my experience. > > Thank you for all your Help. > Hi Luis, The locations suggested for first time configuration could be documented in a new wiki page explaining that this is not the recommended general workflow but does help new users that are not worried about having rxtx installed into the JRE. For a professional environment, the user would want to follow the workflow currently on the wiki and keep their JRE clean. Often the user will not be able to add libraries to the JRE and will need to use their home directory or a sandbox. Feel free to add information to the wiki. I'd suggest creating comment in the current page and have the comment link to what worked for you as a first time user new to Linux. You can create a new page with your comments. In the long term, we will be working on an autoinstaller that works over the web. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Mon May 4 09:15:40 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Mon, 04 May 2009 16:15:40 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FF069C.8040406@ntlworld.com> Hi Trent, I have now installed the package on my 64 bit machine and when I run my program I get errors on the attachment. I know it as something to do with the architecture of my system but I can no figure out how to fix it. I have built it from source again, I did not transfer the files from machine to machine. can you please put me in the right direction. Thank you very much for your help. Best Regards Luis -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshoot.png Type: image/png Size: 25753 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090504/141ab5dc/attachment-0010.png From johnny.luong at trustcommerce.com Mon May 4 11:57:08 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 04 May 2009 10:57:08 -0700 Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FF069C.8040406@ntlworld.com> References: <49FF069C.8040406@ntlworld.com> Message-ID: <49FF2C74.90805@trustcommerce.com> Luis Moreira wrote: > Hi Trent, > I have now installed the package on my 64 bit machine and when I run my > program I get errors on the attachment. I know it as something to do > with the architecture of my system but I can no figure out how to fix > it. I have built it from source again, I did not transfer the files from > machine to machine. > can you please put me in the right direction. > Thank you very much for your help. > Best Regards > Luis > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Hi, Does running it on a 64-bit JVM help? Your host environment might be building objects for a 64-bit environment unless you did a cross-compile... -- you can find out by doing something like the following: johnny at spike:~$ java -version java version "1.6.0_0" OpenJDK Runtime Environment (build 1.6.0_0-b11) OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode) johnny at spike:~$ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) -Johnny From huangdongkai at gmail.com Wed May 6 11:06:06 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 01:06:06 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. Message-ID: Dear all, I recompile the rxtxSerial source code by MinGW32 and compile success. But when I run my Application which use rxtxSerial.dll to communicate with serial port, a runtime exception happened and application crash. I have no idea why it can not work, beacuse i have not change any source code of rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I have missed when compile the source code on Window NT? Here below is the output error massage. # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, tid=1360 # # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing windows-x86) # Problematic frame: # V [jvm.dll+0x1b6824] # # An error report file with more information is saved as: # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/32c1e699/attachment-0008.html From tjarvi at qbang.org Wed May 6 20:04:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 May 2009 20:04:10 -0600 (MDT) Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: On Thu, 7 May 2009, dongkai huang wrote: > Dear all, > ????? I recompile the rxtxSerial source code by MinGW32 and compile success. > But when I run my Application which use rxtxSerial.dll to communicate with > serial port, a runtime exception happened and application crash.? I have no > idea why it can not work, beacuse i have not change any source code of > rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I > have missed when compile the source code on Window NT? Here below is the > output error massage. > # > # An unexpected error has been detected by Java Runtime Environment: > # > #? EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, > tid=1360 > # > # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing > windows-x86) > > # Problematic frame: > # V? [jvm.dll+0x1b6824] > # > # An error report file with more information is saved as: > # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log > # > # If you would like to submit a bug report, please visit: > #?? http://java.sun.com/webapps/bugreport/crash.jsp > # > > > Hi Dongkai Could you explain how you compiled rxtx with mingw? Did you run configure? Was the compiler native or a cross compiler (like compiling on Linux for Windows)? Is the crash happening when you first open the port or is it happening randomly later on? -- Trent Jarvi tjarvi at qbang.org From huangdongkai at gmail.com Wed May 6 20:48:56 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 10:48:56 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Hi Trent, I was followed the step on INSTALL file, did not run the configure, I used the Makefile.mingw32 which include on the source code package, and only change some path( jdk home path etc.). And I use the native compiler on Windows. The crash happened on I call the getPortIdentifiers() every time. On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Dear all, >> I recompile the rxtxSerial source code by MinGW32 and compile >> success. >> But when I run my Application which use rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and application crash. I have >> no >> idea why it can not work, beacuse i have not change any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing >> I >> have missed when compile the source code on Window NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is saved as: >> # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> > Hi Dongkai > > Could you explain how you compiled rxtx with mingw? Did you run configure? > Was the compiler native or a cross compiler (like compiling on Linux for > Windows)? > > Is the crash happening when you first open the port or is it happening > randomly later on? > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/733eded5/attachment-0008.html From m.j.tandy at warwick.ac.uk Thu May 7 10:39:12 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 7 May 2009 17:39:12 +0100 Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. Message-ID: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> I've encountered a bug in how XON/XOFF are handled on Windows. The symptoms were: 1. XON/XOFF from device to PC did not stop transmission. 2. XON/XOFF characters were present in data read from serial port input stream, when it was expected that they would be stripped out. 3. Investigation with SysInternals PortMon revealed the following configuration when using rxtx: 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 while HyperTerminal, which did not have the same problems as me, produced the following: 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 In other words, the problem is that, in addition to being told to use XON/XOFF flow control, the computer has to explicitly be told which characters to use for 'XON' and 'XOFF'. This part of the configuration was being missed out. I got the latest rxtx source from CVS, and identified the problem as an omission in the 'init_termios' function of 'termios.c', which configures the unix/termios 'c_cc' (control characters) data structure - but omits to configure the VSTART and VSTOP control characters. Later, the termios c_cc data structure is translated (by termios_to_DCB) into a data structure named 'DCB', which is passed to the windows serial port configuration interface. By adding two lines defining the standard XON/XOFF characters to the function init_termios, the bug is fixed. A patch doing this is attached. Thanks, Michael Tandy -------------- next part -------------- A non-text attachment was scrubbed... Name: xon-xoff.diff Type: application/octet-stream Size: 667 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/159c0dcc/attachment-0007.obj From tjarvi at qbang.org Thu May 7 17:57:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 May 2009 17:57:28 -0600 (MDT) Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. In-Reply-To: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> References: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> Message-ID: On Thu, 7 May 2009, Michael Tandy wrote: > I've encountered a bug in how XON/XOFF are handled on Windows. > > The symptoms were: > 1. XON/XOFF from device to PC did not stop transmission. > 2. XON/XOFF characters were present in data read from serial port > input stream, when it was expected that they would be stripped out. > 3. Investigation with SysInternals PortMon revealed the following > configuration when using rxtx: > > 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 > BRK:0 EVT:a XON:0 XOFF:0 > > while HyperTerminal, which did not have the same problems as me, > produced the following: > > 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 > > In other words, the problem is that, in addition to being told to use > XON/XOFF flow control, the computer has to explicitly be told which > characters to use for 'XON' and 'XOFF'. This part of the configuration > was being missed out. > > I got the latest rxtx source from CVS, and identified the problem as > an omission in the 'init_termios' function of 'termios.c', which > configures the unix/termios 'c_cc' (control characters) data structure > - but omits to configure the VSTART and VSTOP control characters. > Later, the termios c_cc data structure is translated (by > termios_to_DCB) into a data structure named 'DCB', which is passed to > the windows serial port configuration interface. > > By adding two lines defining the standard XON/XOFF characters to the > function init_termios, the bug is fixed. A patch doing this is > attached. > Thanks Michael, Good timing. I plan on releasing rxtx-2.2 this coming Sunday. -- Trent Jarvi tjarvi at qbang.org From wjr at weru.ksu.edu Fri May 8 11:38:29 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Fri, 08 May 2009 12:38:29 -0500 Subject: [Rxtx] swing jfilechooser lockup Message-ID: <4A046E15.6010907@weru.ksu.edu> Hi, I wrote a small swing app to download images from an industrial camera. I used the two way serial sample code as a starting point. The app works fine EXCEPT for a call to jfilechooser. After I open the comm port and then try to change the output directory or log file, the jfilechooser winds up trying to unpark (note, parking is not something I'm really familiar with) and doesn't. If I try to change the file or directory before I start the comm port, it works. If I click on menu items that don't call jfilechooser, everything is OK. If I try closing the comm port and then try to create a jfilechooser, it locks up. There is obviously some sort of deadlock here because the awt thread starts waiting on something but it's not clear what. I haven't gone thru the rxtx code yet because it's not in the file structure that netbeans wants for debugging purposes. However, debugging code that I don't have a clear idea of what it is supposed to do is not my idea of a good time. Does anyone have any ideas on what is going on here? Thanks, wjr From Bob_Jacobsen at lbl.gov Fri May 8 14:48:25 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Fri, 8 May 2009 13:48:25 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A046E15.6010907@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> Message-ID: At 12:38 PM -0500 5/8/09, Bill Rust wrote: >Hi, > >I wrote a small swing app to download images from an industrial camera. >I used the two way serial sample code as a starting point. The app works >fine EXCEPT for a call to jfilechooser. After I open the comm port and >then try to change the output directory or log file, the jfilechooser >winds up trying to unpark (note, parking is not something I'm really >familiar with) and doesn't. If I try to change the file or directory >before I start the comm port, it works. If I click on menu items that >don't call jfilechooser, everything is OK. If I try closing the comm >port and then try to create a jfilechooser, it locks up. There is >obviously some sort of deadlock here because the awt thread starts >waiting on something but it's not clear what. I haven't gone thru the >rxtx code yet because it's not in the file structure that netbeans wants >for debugging purposes. However, debugging code that I don't have a >clear idea of what it is supposed to do is not my idea of a good time. What is the threading structure of your code? The various high-function Swing components, such as JFileChooser, are notorious for doing Really Bad Stuff when invoked from off the Swing thread. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From bschlining at gmail.com Fri May 8 15:08:50 2009 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 8 May 2009 14:08:50 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: Bob's probably right...take look at javax.swing.SwingUtilites for the workaround to get your swing stuff invoked on the EventDispatchThread (EDT). Some swing-methods do work when called outside of the EDT, but just to be safe, do your creation and swing calls on the EDT. It's really simple, here's an example of a synchronous call. // Here's how to run stuff on the EDT from a different thread SwingUtilities.invokeAndWait(new Runnable() { public void run() { JFileChooser fc; // create, setup, show your filechooser // Get the result from the filechooser } }); To do a asynchronous call use SwingUtilities.invokeLater > >I wrote a small swing app to download images from an industrial camera. > >I used the two way serial sample code as a starting point. The app works > >fine EXCEPT for a call to jfilechooser. After I open the comm port and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090508/c21c2127/attachment-0006.html From tod at todbot.com Fri May 8 16:27:12 2009 From: tod at todbot.com (Tod E. Kurt) Date: Fri, 8 May 2009 15:27:12 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> This is the exact technique I use to let the user choose which serial port to use on startup. Here's a method I've got in many of my sketches: void choosePort() { String portlist[] = Serial.list(); String port = null; javax.swing.SwingUtilities.invokeLater(new Runnable() { public void run() { try { String port = (String) javax.swing.JOptionPane.showInputDialog( null, "Select Serial Port", "MySuperSketch", javax.swing.JOptionPane.QUESTION_MESSAGE, null, portlist, null); if( port == null ) { javax.swing.JOptionPane.showMessageDialog(null, "No port chosen, goodbye"); System.exit(1); } serialPort = port; } catch (Exception e) { e.printStackTrace(); } } } ); } On May 8, 2009, at 2:08 p, Brian Schlining wrote: > Bob's probably right...take look at javax.swing.SwingUtilites for > the workaround to get your swing stuff invoked on the > EventDispatchThread (EDT). Some swing-methods do work when called > outside of the EDT, but just to be safe, do your creation and swing > calls on the EDT. It's really simple, here's an example of a > synchronous call. > > // Here's how to run stuff on the EDT from a different thread > SwingUtilities.invokeAndWait(new Runnable() { > public void run() { > JFileChooser fc; // create, setup, show your filechooser > // Get the result from the filechooser > } > }); > > To do a asynchronous call use SwingUtilities.invokeLater > > > >I wrote a small swing app to download images from an industrial > camera. > >I used the two way serial sample code as a starting point. The app > works > >fine EXCEPT for a call to jfilechooser. After I open the comm port > and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From huangdongkai at gmail.com Sat May 9 04:46:22 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Sat, 9 May 2009 18:46:22 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Dear Trent, After I intsall the ming32-cross compile to compile the rxtxSerial.dll and testing, i found the same problem still exist. I am not sure my compiler version is the same as your's. Could you tell me the way you can success compile rxtx-2.1-7r2 release source code? Thanks for you kindly help. On Fri, May 8, 2009 at 8:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Hi Trent, >> The attach is the Make file I use to compile the rxtx. >> >> On Thu, May 7, 2009 at 10:48 AM, dongkai huang >> wrote: >> Hi Trent, >> I was followed the step on INSTALL file, did not run the >> configure, I used the Makefile.mingw32 which include on the >> source code package, and only change some path( jdk home path >> etc.). And I use the native compiler on Windows. >> The crash happened on I call the getPortIdentifiers() >> every time. >> >> On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: >> >> >> On Thu, 7 May 2009, dongkai huang wrote: >> >> Dear all, >> I recompile the rxtxSerial source code by >> MinGW32 and compile success. >> But when I run my Application which use >> rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and >> application crash. I have no >> idea why it can not work, beacuse i have not change >> any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source >> code. Did some thing I >> have missed when compile the source code on Window >> NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java >> Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at >> pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 >> mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is >> saved as: >> # >> D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please >> visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> >> Hi Dongkai >> >> Could you explain how you compiled rxtx with mingw? Did you run >> configure? Was the compiler native or a cross compiler (like >> compiling on Linux for Windows)? >> >> Is the crash happening when you first open the port or is it >> happening randomly later on? >> >> > Thanks Dongkai > > I'll look at your Makefile tomorrow. Which version of mingw was this? > > I suspect there is a problem with that makefile. I usually built that > version of rxtx for windows with a mingw32 cross compiler using the > configure script. > > The configure script may well work for you if you have a cygwin environment > with mingw instead of gcc. I'll take a look at what is different. > > -- > > Trent Jarvi > tjarvi at qbang.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090509/b729c429/attachment-0005.html From wjr at weru.ksu.edu Wed May 13 15:50:30 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Wed, 13 May 2009 16:50:30 -0500 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> Message-ID: <4A0B40A6.5070204@weru.ksu.edu> Tod's solution misses the point. He is picking and opening the serial port. That's the step before where my problem occurs. To recap: 1. I have a simple java swing app. 2. On the menu bar, there is the standard set, file, etc., of jmenu's. Under file, there is a jmenuitem, logfileopen, which pops up a jfilechooser to select a logfile and another jmenuitem, setprefix, which pops up a jdialog to allow the user to type in a file name prefix for downloaded images. 3. There is another jmenuitem that starts the commport running. 4. When logfileopen is pressed before the commport is started, it works. 5. When logfileopen is pressed after the commport is started, it hangs. 6. setprefix works whether or not the commport is started. 7. portIdentifier.open starts a thread that goes into a native method, RXTXPort.eventLoop, and never returns. 8. java.sun bugs has a bug report, 6741890, that is similar but their workaround doesn't. 9. When it locks up, there is a swing-shell thread that appears to be down in some native libraries, winshellfolder2 10. The awt-eventQ thread is unblocked but in code that says its parked. If you have anymore ideas, I'd really appreciate them. wjr Tod E. Kurt wrote: > This is the exact technique I use to let the user choose which serial > port to use on startup. Here's a method I've got in many of my sketches: > > void choosePort() { > String portlist[] = Serial.list(); > String port = null; > javax.swing.SwingUtilities.invokeLater(new Runnable() { > public void run() { > try { > String port = (String) javax.swing.JOptionPane.showInputDialog( > null, > "Select Serial Port", > "MySuperSketch", > javax.swing.JOptionPane.QUESTION_MESSAGE, > null, portlist, null); > if( port == null ) { > javax.swing.JOptionPane.showMessageDialog(null, "No port > chosen, goodbye"); > System.exit(1); > } > serialPort = port; > } > catch (Exception e) { > e.printStackTrace(); > } > } > } ); > } > > > On May 8, 2009, at 2:08 p, Brian Schlining wrote: > >> Bob's probably right...take look at javax.swing.SwingUtilites for the >> workaround to get your swing stuff invoked on the EventDispatchThread >> (EDT). Some swing-methods do work when called outside of the EDT, but >> just to be safe, do your creation and swing calls on the EDT. It's >> really simple, here's an example of a synchronous call. >> >> // Here's how to run stuff on the EDT from a different thread >> SwingUtilities.invokeAndWait(new Runnable() { >> public void run() { >> JFileChooser fc; // create, setup, show your filechooser >> // Get the result from the filechooser >> } >> }); >> >> To do a asynchronous call use SwingUtilities.invokeLater >> >> >> >I wrote a small swing app to download images from an industrial camera. >> >I used the two way serial sample code as a starting point. The app works >> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >> >then try to change the output directory or log file, the jfilechooser >> >winds up trying to unpark (note, parking is not something I'm really >> >familiar with) and doesn't. >> What is the threading structure of your code? >> >> The various high-function Swing components, such as JFileChooser, are >> notorious for doing Really Bad Stuff when invoked from off the Swing >> thread. >> >> Bob >> -- >> Bob Jacobsen, UC Berkeley >> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >> JacobsenRG >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -- >> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >> Brian Schlining >> bschlining at gmail.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx From m.j.tandy at warwick.ac.uk Wed May 13 16:42:24 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 13 May 2009 23:42:24 +0100 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A0B40A6.5070204@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> <4A0B40A6.5070204@weru.ksu.edu> Message-ID: <302aa0340905131542i601ec3f1w3b0b5879c23f8eca@mail.gmail.com> Perhaps you could post your program, or an excerpt of it sufficient to demonstrate the problem you're having, for us to have a look at? 2009/5/13 Bill Rust : > Tod's solution misses the point. He is picking and opening the serial > port. That's the step before where my problem occurs. > > To recap: > > 1. I have a simple java swing app. > 2. On the menu bar, there is the standard set, file, etc., of jmenu's. > Under file, there is a jmenuitem, logfileopen, which pops up a > jfilechooser to select a logfile and another jmenuitem, setprefix, which > pops up a jdialog to allow the user to type in a file name prefix for > downloaded images. > 3. There is another jmenuitem that starts the commport running. > 4. When logfileopen is pressed before the commport is started, it works. > 5. When logfileopen is pressed after the commport is started, it hangs. > 6. setprefix works whether or not the commport is started. > 7. portIdentifier.open starts a thread that goes into a native > method, ? ? ? ? ? ? ? ? ? ? ? ? RXTXPort.eventLoop, and never returns. > 8. java.sun bugs has a bug report, 6741890, that is similar but > their ? ? ? ? ? ? ? ? ? workaround doesn't. > 9. When it locks up, there is a swing-shell thread that appears to be > ? ? ? ?down in some native libraries, winshellfolder2 > 10. The awt-eventQ thread is unblocked but in code that says its parked. > > If you have anymore ideas, I'd really appreciate them. > > wjr > > Tod E. Kurt wrote: >> This is the exact technique I use to let the user choose which serial >> port to use on startup. ?Here's a method I've got in many of my sketches: >> >> void choosePort() { >> ? String portlist[] = Serial.list(); >> ? String port = null; >> ? javax.swing.SwingUtilities.invokeLater(new Runnable() { >> ? ? public void run() { >> ? ? ? try { >> ? ? ? ? String port = (String) javax.swing.JOptionPane.showInputDialog( >> null, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Select Serial Port", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "MySuperSketch", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? javax.swing.JOptionPane.QUESTION_MESSAGE, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? null, portlist, null); >> ? ? ? ? if( port == null ) ?{ >> ? ? ? ? ? javax.swing.JOptionPane.showMessageDialog(null, "No port >> chosen, goodbye"); >> ? ? ? ? ? System.exit(1); >> ? ? ? ? } >> ? ? ? ? serialPort = port; >> ? ? ? } >> ? ? ? catch (Exception e) { >> ? ? ? ? e.printStackTrace(); >> ? ? ? } >> ? ? } >> ? } ); >> } >> >> >> On May 8, 2009, at 2:08 p, Brian Schlining wrote: >> >>> Bob's probably right...take look at javax.swing.SwingUtilites for the >>> workaround to get your swing stuff invoked on the EventDispatchThread >>> (EDT). Some swing-methods do work when called outside of the EDT, but >>> just to be safe, do your creation and swing calls on the EDT. It's >>> really simple, here's an example of a synchronous call. >>> >>> // Here's how to run stuff on the EDT from a different thread >>> SwingUtilities.invokeAndWait(new Runnable() { >>> ? ? ? public void run() { >>> ? ? ? ? ? ?JFileChooser fc; // create, setup, show your filechooser >>> ? ? ? ? ? ?// Get the result from the filechooser >>> ? ? ? } >>> }); >>> >>> To do a asynchronous call use SwingUtilities.invokeLater >>> >>> >>> >I wrote a small swing app to download images from an industrial camera. >>> >I used the two way serial sample code as a starting point. The app works >>> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >>> >then try to change the output directory or log file, the jfilechooser >>> >winds up trying to unpark (note, parking is not something I'm really >>> >familiar with) and doesn't. >>> What is the threading structure of your code? >>> >>> The various high-function Swing components, such as JFileChooser, are >>> notorious for doing Really Bad Stuff when invoked from off the Swing >>> thread. >>> >>> Bob >>> -- >>> Bob Jacobsen, UC Berkeley >>> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >>> JacobsenRG >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >>> -- >>> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >>> Brian Schlining >>> bschlining at gmail.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From m.j.tandy at warwick.ac.uk Thu May 14 03:05:36 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 14 May 2009 10:05:36 +0100 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A0B40A6.5070204@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> <4A0B40A6.5070204@weru.ksu.edu> Message-ID: <302aa0340905140205p6ceb5a9br24e00a50e9cafa5@mail.gmail.com> Java has a built in deadlock detection utility; run your program from the command line, then (on windows) press Ctrl+Break (On Linux, Ctrl+\ does the trick I'm told). That should produce status information and a stack trace for every running thread, including locks held and locks waited on. Maybe that would contain enough information for you to work out what's locking what? 2009/5/13 Bill Rust : > Tod's solution misses the point. He is picking and opening the serial > port. That's the step before where my problem occurs. > > To recap: > > 1. I have a simple java swing app. > 2. On the menu bar, there is the standard set, file, etc., of jmenu's. > Under file, there is a jmenuitem, logfileopen, which pops up a > jfilechooser to select a logfile and another jmenuitem, setprefix, which > pops up a jdialog to allow the user to type in a file name prefix for > downloaded images. > 3. There is another jmenuitem that starts the commport running. > 4. When logfileopen is pressed before the commport is started, it works. > 5. When logfileopen is pressed after the commport is started, it hangs. > 6. setprefix works whether or not the commport is started. > 7. portIdentifier.open starts a thread that goes into a native > method, ? ? ? ? ? ? ? ? ? ? ? ? RXTXPort.eventLoop, and never returns. > 8. java.sun bugs has a bug report, 6741890, that is similar but > their ? ? ? ? ? ? ? ? ? workaround doesn't. > 9. When it locks up, there is a swing-shell thread that appears to be > ? ? ? ?down in some native libraries, winshellfolder2 > 10. The awt-eventQ thread is unblocked but in code that says its parked. > > If you have anymore ideas, I'd really appreciate them. > > wjr > > Tod E. Kurt wrote: >> This is the exact technique I use to let the user choose which serial >> port to use on startup. ?Here's a method I've got in many of my sketches: >> >> void choosePort() { >> ? String portlist[] = Serial.list(); >> ? String port = null; >> ? javax.swing.SwingUtilities.invokeLater(new Runnable() { >> ? ? public void run() { >> ? ? ? try { >> ? ? ? ? String port = (String) javax.swing.JOptionPane.showInputDialog( >> null, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Select Serial Port", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "MySuperSketch", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? javax.swing.JOptionPane.QUESTION_MESSAGE, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? null, portlist, null); >> ? ? ? ? if( port == null ) ?{ >> ? ? ? ? ? javax.swing.JOptionPane.showMessageDialog(null, "No port >> chosen, goodbye"); >> ? ? ? ? ? System.exit(1); >> ? ? ? ? } >> ? ? ? ? serialPort = port; >> ? ? ? } >> ? ? ? catch (Exception e) { >> ? ? ? ? e.printStackTrace(); >> ? ? ? } >> ? ? } >> ? } ); >> } >> >> >> On May 8, 2009, at 2:08 p, Brian Schlining wrote: >> >>> Bob's probably right...take look at javax.swing.SwingUtilites for the >>> workaround to get your swing stuff invoked on the EventDispatchThread >>> (EDT). Some swing-methods do work when called outside of the EDT, but >>> just to be safe, do your creation and swing calls on the EDT. It's >>> really simple, here's an example of a synchronous call. >>> >>> // Here's how to run stuff on the EDT from a different thread >>> SwingUtilities.invokeAndWait(new Runnable() { >>> ? ? ? public void run() { >>> ? ? ? ? ? ?JFileChooser fc; // create, setup, show your filechooser >>> ? ? ? ? ? ?// Get the result from the filechooser >>> ? ? ? } >>> }); >>> >>> To do a asynchronous call use SwingUtilities.invokeLater >>> >>> >>> >I wrote a small swing app to download images from an industrial camera. >>> >I used the two way serial sample code as a starting point. The app works >>> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >>> >then try to change the output directory or log file, the jfilechooser >>> >winds up trying to unpark (note, parking is not something I'm really >>> >familiar with) and doesn't. >>> What is the threading structure of your code? >>> >>> The various high-function Swing components, such as JFileChooser, are >>> notorious for doing Really Bad Stuff when invoked from off the Swing >>> thread. >>> >>> Bob >>> -- >>> Bob Jacobsen, UC Berkeley >>> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >>> JacobsenRG >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >>> -- >>> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >>> Brian Schlining >>> bschlining at gmail.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From luis.moreira at ntlworld.com Sat May 2 00:39:04 2009 From: luis.moreira at ntlworld.com (luis.moreira at ntlworld.com) Date: Sat, 2 May 2009 7:39:04 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Hi Travis, The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. The issues I still have is the errors after that. Do you have any idea what can be causing this errors? _______________________________________________________________________________ conftest.c: In function 'main': conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) conftest.c:8: error: (Each undeclared identifier is reported only once conftest.c:8: error: for each function it appears in.) conftest.c:8: error: expected ')' before string constant conftest.c:8: warning: format not a string literal and no format arguments ./configure: line 21462: ./conftest: No such file or directory ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands ------------------------------------------------------------------------------- I don't know what happened to my previous post, it as not showed up in the list. Best Regards Luis From tjarvi at qbang.org Sat May 2 07:30:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 07:30:04 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> References: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Message-ID: On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > Hi Travis, > The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. > The issues I still have is the errors after that. Do you have any idea what can be causing this errors? > > _______________________________________________________________________________ > conftest.c: In function 'main': > conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) > conftest.c:8: error: (Each undeclared identifier is reported only once > conftest.c:8: error: for each function it appears in.) > conftest.c:8: error: expected ')' before string constant > conftest.c:8: warning: format not a string literal and no format arguments > ./configure: line 21462: ./conftest: No such file or directory > ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: config.h is unchanged > config.status: executing depfiles commands > ------------------------------------------------------------------------------- > > This was corrected in CVS. I think you can just do the following in the top directory: cvs login: (pw is mousy) cvs update That will get the current fixes. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sat May 2 16:14:50 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sat, 02 May 2009 23:14:50 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FCC5DA.6000700@ntlworld.com> Trent Jarvi wrote: > > > On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > >> Hi Travis, >> The problem with the Makefile is not a problem,When I run ./configure >> I make a new Makefile with the same data in it, hence what I just >> modified is removed. >> The issues I still have is the errors after that. Do you have any >> idea what can be causing this errors? >> >> _______________________________________________________________________________ >> >> conftest.c: In function 'main': >> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >> function) >> conftest.c:8: error: (Each undeclared identifier is reported only once >> conftest.c:8: error: for each function it appears in.) >> conftest.c:8: error: expected ')' before string constant >> conftest.c:8: warning: format not a string literal and no format >> arguments >> ./configure: line 21462: ./conftest: No such file or directory >> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >> expected >> configure: creating ./config.status >> config.status: creating Makefile >> config.status: creating config.h >> config.status: config.h is unchanged >> config.status: executing depfiles commands >> ------------------------------------------------------------------------------- >> >> >> > > This was corrected in CVS. I think you can just do the following in > the top directory: > > cvs login: (pw is mousy) > cvs update > > That will get the current fixes. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, apologies for the mix-up of your name. I managed to get further on by updating CVS, the configure command gets to the end without any errors, it still warns me that it is confused about where to find the jni_md.h but I just edited the Makefile and sorted that out. I then run make, with no parameters following the instructions on the Wiki, but that generated a few more errors: ----------------------------------------------------------------------------------------------------------------------- gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. -I/usr/lib/jvm/java-6-openjdk/include /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' undeclared (first use in this function) /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared identifier is reported only once /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each function it appears in.) libtool: link: `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 ----------------------------------------------------------------------------------------------------------------------- Another question I have is, in which folder will the .so files be placed after make finishes? thank you very much for your help. Best Regards Luis From tjarvi at qbang.org Sat May 2 19:27:08 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 19:27:08 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FCC5DA.6000700@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> Message-ID: On Sat, 2 May 2009, Luis Moreira wrote: > Trent Jarvi wrote: >> >> >> On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: >> >>> Hi Travis, >>> The problem with the Makefile is not a problem,When I run ./configure >>> I make a new Makefile with the same data in it, hence what I just >>> modified is removed. >>> The issues I still have is the errors after that. Do you have any >>> idea what can be causing this errors? >>> >>> _______________________________________________________________________________ >>> >>> conftest.c: In function 'main': >>> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >>> function) >>> conftest.c:8: error: (Each undeclared identifier is reported only once >>> conftest.c:8: error: for each function it appears in.) >>> conftest.c:8: error: expected ')' before string constant >>> conftest.c:8: warning: format not a string literal and no format >>> arguments >>> ./configure: line 21462: ./conftest: No such file or directory >>> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >>> expected >>> configure: creating ./config.status >>> config.status: creating Makefile >>> config.status: creating config.h >>> config.status: config.h is unchanged >>> config.status: executing depfiles commands >>> ------------------------------------------------------------------------------- >>> >>> >>> >> >> This was corrected in CVS. I think you can just do the following in >> the top directory: >> >> cvs login: (pw is mousy) >> cvs update >> >> That will get the current fixes. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > apologies for the mix-up of your name. > I managed to get further on by updating CVS, the configure command gets > to the end without any errors, it still warns me that it is confused > about where to find the jni_md.h but I just edited the Makefile and > sorted that out. > I then run make, with no parameters following the instructions on the > Wiki, but that generated a few more errors: > ----------------------------------------------------------------------------------------------------------------------- > > gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. > -I/usr/lib/jvm/java-6-openjdk/include > /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE > -D_BSD_SOURCE -D__need_timespec -c > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o > /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' > undeclared (first use in this function) > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared > identifier is reported only once > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each > function it appears in.) > libtool: link: > `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a > valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 > ----------------------------------------------------------------------------------------------------------------------- > > Another question I have is, in which folder will the .so files be placed > after make finishes? > > thank you very much for your help. > Ah when you do cvs update pass the -Pd option cvs update -Pd Also, when you run configure, use --disable-PRINTER to only build the serial support. It will make things easier. --disable-LOCKFILES will also be easier to get going until you want to learn about how to prevent multiple applications from reading the same serial port. The link for debugging will describe where the files go. By default, it will install in the JRE/JDK under jre/lib/ext (the jar file) jre/lib/i386 (the .so file) Those are on the proper paths when you use the sun or ibm jdk. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sun May 3 01:30:43 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sun, 03 May 2009 08:30:43 +0100 Subject: [Rxtx] First use of RXTX package In-Reply-To: References: <49FCC5DA.6000700@ntlworld.com> Message-ID: <49FD4823.5080204@ntlworld.com> Ah > > when you do cvs update pass the -Pd option > > cvs update -Pd > > Also, when you run configure, use --disable-PRINTER to only build the > serial support. It will make things easier. --disable-LOCKFILES will > also be easier to get going until you want to learn about how to > prevent multiple applications from reading the same serial port. > > The link for debugging will describe where the files go. By default, > it will install in the JRE/JDK under > > jre/lib/ext (the jar file) > jre/lib/i386 (the .so file) > > Those are on the proper paths when you use the sun or ibm jdk. > > http://rxtx.qbang.org/wiki/index.php/Trouble_shooting > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, It as done it! I think this instructions you gave me should be on the Wiki, I can write them for you if you like. Also on the Wiki when you describe the three methods of installing the RxTx package it is confusing because as far as I can see, you always have to do method 1 or the .so files will not be generated(is this correct?). Then you can if you like change the location with method 1 & 2. Is it possible to modify the .la file to point to different directories for installation and then you can decide where to place the files? In a way I have learned quite a lot about Linux by having to struggle, with your help, to find solutions to the problems I encountered (I am still very new to Linux), but maybe we need to log these problems somewhere to make it less of a struggle for others like me. I have used the PortLister example to test it and it came up with my USB to dual Serial adaptor Ports. I will now explore the RxTx package, before I tackle the windows installation, I will let you know of my experience. Thank you for all your Help. Best Regards Luis From tjarvi at qbang.org Sun May 3 10:37:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 3 May 2009 10:37:50 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FD4823.5080204@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> <49FD4823.5080204@ntlworld.com> Message-ID: On Sun, 3 May 2009, Luis Moreira wrote: > Ah >> >> when you do cvs update pass the -Pd option >> >> cvs update -Pd >> >> Also, when you run configure, use --disable-PRINTER to only build the >> serial support. It will make things easier. --disable-LOCKFILES will >> also be easier to get going until you want to learn about how to >> prevent multiple applications from reading the same serial port. >> >> The link for debugging will describe where the files go. By default, >> it will install in the JRE/JDK under >> >> jre/lib/ext (the jar file) >> jre/lib/i386 (the .so file) >> >> Those are on the proper paths when you use the sun or ibm jdk. >> >> http://rxtx.qbang.org/wiki/index.php/Trouble_shooting >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > It as done it! > I think this instructions you gave me should be on the Wiki, I can write > them for you if you like. Also on the Wiki when you describe the three > methods of installing the RxTx package it is confusing because as far > as I can see, you always have to do method 1 or the .so files will not > be generated(is this correct?). Then you can if you like change the > location with method 1 & 2. Is it possible to modify the .la file to > point to different directories for installation and then you can decide > where to place the files? > In a way I have learned quite a lot about Linux by having to struggle, > with your help, to find solutions to the problems I encountered (I am > still very new to Linux), but maybe we need to log these problems > somewhere to make it less of a struggle for others like me. > > I have used the PortLister example to test it and it came up with my USB > to dual Serial adaptor Ports. > > I will now explore the RxTx package, before I tackle the windows > installation, I will let you know of my experience. > > Thank you for all your Help. > Hi Luis, The locations suggested for first time configuration could be documented in a new wiki page explaining that this is not the recommended general workflow but does help new users that are not worried about having rxtx installed into the JRE. For a professional environment, the user would want to follow the workflow currently on the wiki and keep their JRE clean. Often the user will not be able to add libraries to the JRE and will need to use their home directory or a sandbox. Feel free to add information to the wiki. I'd suggest creating comment in the current page and have the comment link to what worked for you as a first time user new to Linux. You can create a new page with your comments. In the long term, we will be working on an autoinstaller that works over the web. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Mon May 4 09:15:40 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Mon, 04 May 2009 16:15:40 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FF069C.8040406@ntlworld.com> Hi Trent, I have now installed the package on my 64 bit machine and when I run my program I get errors on the attachment. I know it as something to do with the architecture of my system but I can no figure out how to fix it. I have built it from source again, I did not transfer the files from machine to machine. can you please put me in the right direction. Thank you very much for your help. Best Regards Luis -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshoot.png Type: image/png Size: 25753 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090504/141ab5dc/attachment-0011.png From johnny.luong at trustcommerce.com Mon May 4 11:57:08 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 04 May 2009 10:57:08 -0700 Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FF069C.8040406@ntlworld.com> References: <49FF069C.8040406@ntlworld.com> Message-ID: <49FF2C74.90805@trustcommerce.com> Luis Moreira wrote: > Hi Trent, > I have now installed the package on my 64 bit machine and when I run my > program I get errors on the attachment. I know it as something to do > with the architecture of my system but I can no figure out how to fix > it. I have built it from source again, I did not transfer the files from > machine to machine. > can you please put me in the right direction. > Thank you very much for your help. > Best Regards > Luis > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Hi, Does running it on a 64-bit JVM help? Your host environment might be building objects for a 64-bit environment unless you did a cross-compile... -- you can find out by doing something like the following: johnny at spike:~$ java -version java version "1.6.0_0" OpenJDK Runtime Environment (build 1.6.0_0-b11) OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode) johnny at spike:~$ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) -Johnny From huangdongkai at gmail.com Wed May 6 11:06:06 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 01:06:06 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. Message-ID: Dear all, I recompile the rxtxSerial source code by MinGW32 and compile success. But when I run my Application which use rxtxSerial.dll to communicate with serial port, a runtime exception happened and application crash. I have no idea why it can not work, beacuse i have not change any source code of rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I have missed when compile the source code on Window NT? Here below is the output error massage. # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, tid=1360 # # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing windows-x86) # Problematic frame: # V [jvm.dll+0x1b6824] # # An error report file with more information is saved as: # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/32c1e699/attachment-0009.html From tjarvi at qbang.org Wed May 6 20:04:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 May 2009 20:04:10 -0600 (MDT) Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: On Thu, 7 May 2009, dongkai huang wrote: > Dear all, > ????? I recompile the rxtxSerial source code by MinGW32 and compile success. > But when I run my Application which use rxtxSerial.dll to communicate with > serial port, a runtime exception happened and application crash.? I have no > idea why it can not work, beacuse i have not change any source code of > rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I > have missed when compile the source code on Window NT? Here below is the > output error massage. > # > # An unexpected error has been detected by Java Runtime Environment: > # > #? EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, > tid=1360 > # > # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing > windows-x86) > > # Problematic frame: > # V? [jvm.dll+0x1b6824] > # > # An error report file with more information is saved as: > # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log > # > # If you would like to submit a bug report, please visit: > #?? http://java.sun.com/webapps/bugreport/crash.jsp > # > > > Hi Dongkai Could you explain how you compiled rxtx with mingw? Did you run configure? Was the compiler native or a cross compiler (like compiling on Linux for Windows)? Is the crash happening when you first open the port or is it happening randomly later on? -- Trent Jarvi tjarvi at qbang.org From huangdongkai at gmail.com Wed May 6 20:48:56 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 10:48:56 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Hi Trent, I was followed the step on INSTALL file, did not run the configure, I used the Makefile.mingw32 which include on the source code package, and only change some path( jdk home path etc.). And I use the native compiler on Windows. The crash happened on I call the getPortIdentifiers() every time. On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Dear all, >> I recompile the rxtxSerial source code by MinGW32 and compile >> success. >> But when I run my Application which use rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and application crash. I have >> no >> idea why it can not work, beacuse i have not change any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing >> I >> have missed when compile the source code on Window NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is saved as: >> # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> > Hi Dongkai > > Could you explain how you compiled rxtx with mingw? Did you run configure? > Was the compiler native or a cross compiler (like compiling on Linux for > Windows)? > > Is the crash happening when you first open the port or is it happening > randomly later on? > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/733eded5/attachment-0009.html From m.j.tandy at warwick.ac.uk Thu May 7 10:39:12 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 7 May 2009 17:39:12 +0100 Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. Message-ID: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> I've encountered a bug in how XON/XOFF are handled on Windows. The symptoms were: 1. XON/XOFF from device to PC did not stop transmission. 2. XON/XOFF characters were present in data read from serial port input stream, when it was expected that they would be stripped out. 3. Investigation with SysInternals PortMon revealed the following configuration when using rxtx: 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 while HyperTerminal, which did not have the same problems as me, produced the following: 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 In other words, the problem is that, in addition to being told to use XON/XOFF flow control, the computer has to explicitly be told which characters to use for 'XON' and 'XOFF'. This part of the configuration was being missed out. I got the latest rxtx source from CVS, and identified the problem as an omission in the 'init_termios' function of 'termios.c', which configures the unix/termios 'c_cc' (control characters) data structure - but omits to configure the VSTART and VSTOP control characters. Later, the termios c_cc data structure is translated (by termios_to_DCB) into a data structure named 'DCB', which is passed to the windows serial port configuration interface. By adding two lines defining the standard XON/XOFF characters to the function init_termios, the bug is fixed. A patch doing this is attached. Thanks, Michael Tandy -------------- next part -------------- A non-text attachment was scrubbed... Name: xon-xoff.diff Type: application/octet-stream Size: 667 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/159c0dcc/attachment-0008.obj From tjarvi at qbang.org Thu May 7 17:57:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 May 2009 17:57:28 -0600 (MDT) Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. In-Reply-To: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> References: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> Message-ID: On Thu, 7 May 2009, Michael Tandy wrote: > I've encountered a bug in how XON/XOFF are handled on Windows. > > The symptoms were: > 1. XON/XOFF from device to PC did not stop transmission. > 2. XON/XOFF characters were present in data read from serial port > input stream, when it was expected that they would be stripped out. > 3. Investigation with SysInternals PortMon revealed the following > configuration when using rxtx: > > 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 > BRK:0 EVT:a XON:0 XOFF:0 > > while HyperTerminal, which did not have the same problems as me, > produced the following: > > 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 > > In other words, the problem is that, in addition to being told to use > XON/XOFF flow control, the computer has to explicitly be told which > characters to use for 'XON' and 'XOFF'. This part of the configuration > was being missed out. > > I got the latest rxtx source from CVS, and identified the problem as > an omission in the 'init_termios' function of 'termios.c', which > configures the unix/termios 'c_cc' (control characters) data structure > - but omits to configure the VSTART and VSTOP control characters. > Later, the termios c_cc data structure is translated (by > termios_to_DCB) into a data structure named 'DCB', which is passed to > the windows serial port configuration interface. > > By adding two lines defining the standard XON/XOFF characters to the > function init_termios, the bug is fixed. A patch doing this is > attached. > Thanks Michael, Good timing. I plan on releasing rxtx-2.2 this coming Sunday. -- Trent Jarvi tjarvi at qbang.org From wjr at weru.ksu.edu Fri May 8 11:38:29 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Fri, 08 May 2009 12:38:29 -0500 Subject: [Rxtx] swing jfilechooser lockup Message-ID: <4A046E15.6010907@weru.ksu.edu> Hi, I wrote a small swing app to download images from an industrial camera. I used the two way serial sample code as a starting point. The app works fine EXCEPT for a call to jfilechooser. After I open the comm port and then try to change the output directory or log file, the jfilechooser winds up trying to unpark (note, parking is not something I'm really familiar with) and doesn't. If I try to change the file or directory before I start the comm port, it works. If I click on menu items that don't call jfilechooser, everything is OK. If I try closing the comm port and then try to create a jfilechooser, it locks up. There is obviously some sort of deadlock here because the awt thread starts waiting on something but it's not clear what. I haven't gone thru the rxtx code yet because it's not in the file structure that netbeans wants for debugging purposes. However, debugging code that I don't have a clear idea of what it is supposed to do is not my idea of a good time. Does anyone have any ideas on what is going on here? Thanks, wjr From Bob_Jacobsen at lbl.gov Fri May 8 14:48:25 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Fri, 8 May 2009 13:48:25 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A046E15.6010907@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> Message-ID: At 12:38 PM -0500 5/8/09, Bill Rust wrote: >Hi, > >I wrote a small swing app to download images from an industrial camera. >I used the two way serial sample code as a starting point. The app works >fine EXCEPT for a call to jfilechooser. After I open the comm port and >then try to change the output directory or log file, the jfilechooser >winds up trying to unpark (note, parking is not something I'm really >familiar with) and doesn't. If I try to change the file or directory >before I start the comm port, it works. If I click on menu items that >don't call jfilechooser, everything is OK. If I try closing the comm >port and then try to create a jfilechooser, it locks up. There is >obviously some sort of deadlock here because the awt thread starts >waiting on something but it's not clear what. I haven't gone thru the >rxtx code yet because it's not in the file structure that netbeans wants >for debugging purposes. However, debugging code that I don't have a >clear idea of what it is supposed to do is not my idea of a good time. What is the threading structure of your code? The various high-function Swing components, such as JFileChooser, are notorious for doing Really Bad Stuff when invoked from off the Swing thread. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From bschlining at gmail.com Fri May 8 15:08:50 2009 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 8 May 2009 14:08:50 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: Bob's probably right...take look at javax.swing.SwingUtilites for the workaround to get your swing stuff invoked on the EventDispatchThread (EDT). Some swing-methods do work when called outside of the EDT, but just to be safe, do your creation and swing calls on the EDT. It's really simple, here's an example of a synchronous call. // Here's how to run stuff on the EDT from a different thread SwingUtilities.invokeAndWait(new Runnable() { public void run() { JFileChooser fc; // create, setup, show your filechooser // Get the result from the filechooser } }); To do a asynchronous call use SwingUtilities.invokeLater > >I wrote a small swing app to download images from an industrial camera. > >I used the two way serial sample code as a starting point. The app works > >fine EXCEPT for a call to jfilechooser. After I open the comm port and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090508/c21c2127/attachment-0007.html From tod at todbot.com Fri May 8 16:27:12 2009 From: tod at todbot.com (Tod E. Kurt) Date: Fri, 8 May 2009 15:27:12 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> This is the exact technique I use to let the user choose which serial port to use on startup. Here's a method I've got in many of my sketches: void choosePort() { String portlist[] = Serial.list(); String port = null; javax.swing.SwingUtilities.invokeLater(new Runnable() { public void run() { try { String port = (String) javax.swing.JOptionPane.showInputDialog( null, "Select Serial Port", "MySuperSketch", javax.swing.JOptionPane.QUESTION_MESSAGE, null, portlist, null); if( port == null ) { javax.swing.JOptionPane.showMessageDialog(null, "No port chosen, goodbye"); System.exit(1); } serialPort = port; } catch (Exception e) { e.printStackTrace(); } } } ); } On May 8, 2009, at 2:08 p, Brian Schlining wrote: > Bob's probably right...take look at javax.swing.SwingUtilites for > the workaround to get your swing stuff invoked on the > EventDispatchThread (EDT). Some swing-methods do work when called > outside of the EDT, but just to be safe, do your creation and swing > calls on the EDT. It's really simple, here's an example of a > synchronous call. > > // Here's how to run stuff on the EDT from a different thread > SwingUtilities.invokeAndWait(new Runnable() { > public void run() { > JFileChooser fc; // create, setup, show your filechooser > // Get the result from the filechooser > } > }); > > To do a asynchronous call use SwingUtilities.invokeLater > > > >I wrote a small swing app to download images from an industrial > camera. > >I used the two way serial sample code as a starting point. The app > works > >fine EXCEPT for a call to jfilechooser. After I open the comm port > and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From huangdongkai at gmail.com Sat May 9 04:46:22 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Sat, 9 May 2009 18:46:22 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Dear Trent, After I intsall the ming32-cross compile to compile the rxtxSerial.dll and testing, i found the same problem still exist. I am not sure my compiler version is the same as your's. Could you tell me the way you can success compile rxtx-2.1-7r2 release source code? Thanks for you kindly help. On Fri, May 8, 2009 at 8:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Hi Trent, >> The attach is the Make file I use to compile the rxtx. >> >> On Thu, May 7, 2009 at 10:48 AM, dongkai huang >> wrote: >> Hi Trent, >> I was followed the step on INSTALL file, did not run the >> configure, I used the Makefile.mingw32 which include on the >> source code package, and only change some path( jdk home path >> etc.). And I use the native compiler on Windows. >> The crash happened on I call the getPortIdentifiers() >> every time. >> >> On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: >> >> >> On Thu, 7 May 2009, dongkai huang wrote: >> >> Dear all, >> I recompile the rxtxSerial source code by >> MinGW32 and compile success. >> But when I run my Application which use >> rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and >> application crash. I have no >> idea why it can not work, beacuse i have not change >> any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source >> code. Did some thing I >> have missed when compile the source code on Window >> NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java >> Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at >> pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 >> mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is >> saved as: >> # >> D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please >> visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> >> Hi Dongkai >> >> Could you explain how you compiled rxtx with mingw? Did you run >> configure? Was the compiler native or a cross compiler (like >> compiling on Linux for Windows)? >> >> Is the crash happening when you first open the port or is it >> happening randomly later on? >> >> > Thanks Dongkai > > I'll look at your Makefile tomorrow. Which version of mingw was this? > > I suspect there is a problem with that makefile. I usually built that > version of rxtx for windows with a mingw32 cross compiler using the > configure script. > > The configure script may well work for you if you have a cygwin environment > with mingw instead of gcc. I'll take a look at what is different. > > -- > > Trent Jarvi > tjarvi at qbang.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090509/b729c429/attachment-0007.html From wjr at weru.ksu.edu Wed May 13 15:50:30 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Wed, 13 May 2009 16:50:30 -0500 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> Message-ID: <4A0B40A6.5070204@weru.ksu.edu> Tod's solution misses the point. He is picking and opening the serial port. That's the step before where my problem occurs. To recap: 1. I have a simple java swing app. 2. On the menu bar, there is the standard set, file, etc., of jmenu's. Under file, there is a jmenuitem, logfileopen, which pops up a jfilechooser to select a logfile and another jmenuitem, setprefix, which pops up a jdialog to allow the user to type in a file name prefix for downloaded images. 3. There is another jmenuitem that starts the commport running. 4. When logfileopen is pressed before the commport is started, it works. 5. When logfileopen is pressed after the commport is started, it hangs. 6. setprefix works whether or not the commport is started. 7. portIdentifier.open starts a thread that goes into a native method, RXTXPort.eventLoop, and never returns. 8. java.sun bugs has a bug report, 6741890, that is similar but their workaround doesn't. 9. When it locks up, there is a swing-shell thread that appears to be down in some native libraries, winshellfolder2 10. The awt-eventQ thread is unblocked but in code that says its parked. If you have anymore ideas, I'd really appreciate them. wjr Tod E. Kurt wrote: > This is the exact technique I use to let the user choose which serial > port to use on startup. Here's a method I've got in many of my sketches: > > void choosePort() { > String portlist[] = Serial.list(); > String port = null; > javax.swing.SwingUtilities.invokeLater(new Runnable() { > public void run() { > try { > String port = (String) javax.swing.JOptionPane.showInputDialog( > null, > "Select Serial Port", > "MySuperSketch", > javax.swing.JOptionPane.QUESTION_MESSAGE, > null, portlist, null); > if( port == null ) { > javax.swing.JOptionPane.showMessageDialog(null, "No port > chosen, goodbye"); > System.exit(1); > } > serialPort = port; > } > catch (Exception e) { > e.printStackTrace(); > } > } > } ); > } > > > On May 8, 2009, at 2:08 p, Brian Schlining wrote: > >> Bob's probably right...take look at javax.swing.SwingUtilites for the >> workaround to get your swing stuff invoked on the EventDispatchThread >> (EDT). Some swing-methods do work when called outside of the EDT, but >> just to be safe, do your creation and swing calls on the EDT. It's >> really simple, here's an example of a synchronous call. >> >> // Here's how to run stuff on the EDT from a different thread >> SwingUtilities.invokeAndWait(new Runnable() { >> public void run() { >> JFileChooser fc; // create, setup, show your filechooser >> // Get the result from the filechooser >> } >> }); >> >> To do a asynchronous call use SwingUtilities.invokeLater >> >> >> >I wrote a small swing app to download images from an industrial camera. >> >I used the two way serial sample code as a starting point. The app works >> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >> >then try to change the output directory or log file, the jfilechooser >> >winds up trying to unpark (note, parking is not something I'm really >> >familiar with) and doesn't. >> What is the threading structure of your code? >> >> The various high-function Swing components, such as JFileChooser, are >> notorious for doing Really Bad Stuff when invoked from off the Swing >> thread. >> >> Bob >> -- >> Bob Jacobsen, UC Berkeley >> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >> JacobsenRG >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -- >> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >> Brian Schlining >> bschlining at gmail.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx From m.j.tandy at warwick.ac.uk Wed May 13 16:42:24 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 13 May 2009 23:42:24 +0100 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A0B40A6.5070204@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> <4A0B40A6.5070204@weru.ksu.edu> Message-ID: <302aa0340905131542i601ec3f1w3b0b5879c23f8eca@mail.gmail.com> Perhaps you could post your program, or an excerpt of it sufficient to demonstrate the problem you're having, for us to have a look at? 2009/5/13 Bill Rust : > Tod's solution misses the point. He is picking and opening the serial > port. That's the step before where my problem occurs. > > To recap: > > 1. I have a simple java swing app. > 2. On the menu bar, there is the standard set, file, etc., of jmenu's. > Under file, there is a jmenuitem, logfileopen, which pops up a > jfilechooser to select a logfile and another jmenuitem, setprefix, which > pops up a jdialog to allow the user to type in a file name prefix for > downloaded images. > 3. There is another jmenuitem that starts the commport running. > 4. When logfileopen is pressed before the commport is started, it works. > 5. When logfileopen is pressed after the commport is started, it hangs. > 6. setprefix works whether or not the commport is started. > 7. portIdentifier.open starts a thread that goes into a native > method, ? ? ? ? ? ? ? ? ? ? ? ? RXTXPort.eventLoop, and never returns. > 8. java.sun bugs has a bug report, 6741890, that is similar but > their ? ? ? ? ? ? ? ? ? workaround doesn't. > 9. When it locks up, there is a swing-shell thread that appears to be > ? ? ? ?down in some native libraries, winshellfolder2 > 10. The awt-eventQ thread is unblocked but in code that says its parked. > > If you have anymore ideas, I'd really appreciate them. > > wjr > > Tod E. Kurt wrote: >> This is the exact technique I use to let the user choose which serial >> port to use on startup. ?Here's a method I've got in many of my sketches: >> >> void choosePort() { >> ? String portlist[] = Serial.list(); >> ? String port = null; >> ? javax.swing.SwingUtilities.invokeLater(new Runnable() { >> ? ? public void run() { >> ? ? ? try { >> ? ? ? ? String port = (String) javax.swing.JOptionPane.showInputDialog( >> null, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Select Serial Port", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "MySuperSketch", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? javax.swing.JOptionPane.QUESTION_MESSAGE, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? null, portlist, null); >> ? ? ? ? if( port == null ) ?{ >> ? ? ? ? ? javax.swing.JOptionPane.showMessageDialog(null, "No port >> chosen, goodbye"); >> ? ? ? ? ? System.exit(1); >> ? ? ? ? } >> ? ? ? ? serialPort = port; >> ? ? ? } >> ? ? ? catch (Exception e) { >> ? ? ? ? e.printStackTrace(); >> ? ? ? } >> ? ? } >> ? } ); >> } >> >> >> On May 8, 2009, at 2:08 p, Brian Schlining wrote: >> >>> Bob's probably right...take look at javax.swing.SwingUtilites for the >>> workaround to get your swing stuff invoked on the EventDispatchThread >>> (EDT). Some swing-methods do work when called outside of the EDT, but >>> just to be safe, do your creation and swing calls on the EDT. It's >>> really simple, here's an example of a synchronous call. >>> >>> // Here's how to run stuff on the EDT from a different thread >>> SwingUtilities.invokeAndWait(new Runnable() { >>> ? ? ? public void run() { >>> ? ? ? ? ? ?JFileChooser fc; // create, setup, show your filechooser >>> ? ? ? ? ? ?// Get the result from the filechooser >>> ? ? ? } >>> }); >>> >>> To do a asynchronous call use SwingUtilities.invokeLater >>> >>> >>> >I wrote a small swing app to download images from an industrial camera. >>> >I used the two way serial sample code as a starting point. The app works >>> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >>> >then try to change the output directory or log file, the jfilechooser >>> >winds up trying to unpark (note, parking is not something I'm really >>> >familiar with) and doesn't. >>> What is the threading structure of your code? >>> >>> The various high-function Swing components, such as JFileChooser, are >>> notorious for doing Really Bad Stuff when invoked from off the Swing >>> thread. >>> >>> Bob >>> -- >>> Bob Jacobsen, UC Berkeley >>> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >>> JacobsenRG >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >>> -- >>> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >>> Brian Schlining >>> bschlining at gmail.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From m.j.tandy at warwick.ac.uk Thu May 14 03:05:36 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 14 May 2009 10:05:36 +0100 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A0B40A6.5070204@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> <4A0B40A6.5070204@weru.ksu.edu> Message-ID: <302aa0340905140205p6ceb5a9br24e00a50e9cafa5@mail.gmail.com> Java has a built in deadlock detection utility; run your program from the command line, then (on windows) press Ctrl+Break (On Linux, Ctrl+\ does the trick I'm told). That should produce status information and a stack trace for every running thread, including locks held and locks waited on. Maybe that would contain enough information for you to work out what's locking what? 2009/5/13 Bill Rust : > Tod's solution misses the point. He is picking and opening the serial > port. That's the step before where my problem occurs. > > To recap: > > 1. I have a simple java swing app. > 2. On the menu bar, there is the standard set, file, etc., of jmenu's. > Under file, there is a jmenuitem, logfileopen, which pops up a > jfilechooser to select a logfile and another jmenuitem, setprefix, which > pops up a jdialog to allow the user to type in a file name prefix for > downloaded images. > 3. There is another jmenuitem that starts the commport running. > 4. When logfileopen is pressed before the commport is started, it works. > 5. When logfileopen is pressed after the commport is started, it hangs. > 6. setprefix works whether or not the commport is started. > 7. portIdentifier.open starts a thread that goes into a native > method, ? ? ? ? ? ? ? ? ? ? ? ? RXTXPort.eventLoop, and never returns. > 8. java.sun bugs has a bug report, 6741890, that is similar but > their ? ? ? ? ? ? ? ? ? workaround doesn't. > 9. When it locks up, there is a swing-shell thread that appears to be > ? ? ? ?down in some native libraries, winshellfolder2 > 10. The awt-eventQ thread is unblocked but in code that says its parked. > > If you have anymore ideas, I'd really appreciate them. > > wjr > > Tod E. Kurt wrote: >> This is the exact technique I use to let the user choose which serial >> port to use on startup. ?Here's a method I've got in many of my sketches: >> >> void choosePort() { >> ? String portlist[] = Serial.list(); >> ? String port = null; >> ? javax.swing.SwingUtilities.invokeLater(new Runnable() { >> ? ? public void run() { >> ? ? ? try { >> ? ? ? ? String port = (String) javax.swing.JOptionPane.showInputDialog( >> null, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Select Serial Port", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "MySuperSketch", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? javax.swing.JOptionPane.QUESTION_MESSAGE, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? null, portlist, null); >> ? ? ? ? if( port == null ) ?{ >> ? ? ? ? ? javax.swing.JOptionPane.showMessageDialog(null, "No port >> chosen, goodbye"); >> ? ? ? ? ? System.exit(1); >> ? ? ? ? } >> ? ? ? ? serialPort = port; >> ? ? ? } >> ? ? ? catch (Exception e) { >> ? ? ? ? e.printStackTrace(); >> ? ? ? } >> ? ? } >> ? } ); >> } >> >> >> On May 8, 2009, at 2:08 p, Brian Schlining wrote: >> >>> Bob's probably right...take look at javax.swing.SwingUtilites for the >>> workaround to get your swing stuff invoked on the EventDispatchThread >>> (EDT). Some swing-methods do work when called outside of the EDT, but >>> just to be safe, do your creation and swing calls on the EDT. It's >>> really simple, here's an example of a synchronous call. >>> >>> // Here's how to run stuff on the EDT from a different thread >>> SwingUtilities.invokeAndWait(new Runnable() { >>> ? ? ? public void run() { >>> ? ? ? ? ? ?JFileChooser fc; // create, setup, show your filechooser >>> ? ? ? ? ? ?// Get the result from the filechooser >>> ? ? ? } >>> }); >>> >>> To do a asynchronous call use SwingUtilities.invokeLater >>> >>> >>> >I wrote a small swing app to download images from an industrial camera. >>> >I used the two way serial sample code as a starting point. The app works >>> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >>> >then try to change the output directory or log file, the jfilechooser >>> >winds up trying to unpark (note, parking is not something I'm really >>> >familiar with) and doesn't. >>> What is the threading structure of your code? >>> >>> The various high-function Swing components, such as JFileChooser, are >>> notorious for doing Really Bad Stuff when invoked from off the Swing >>> thread. >>> >>> Bob >>> -- >>> Bob Jacobsen, UC Berkeley >>> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >>> JacobsenRG >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >>> -- >>> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >>> Brian Schlining >>> bschlining at gmail.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From luis.moreira at ntlworld.com Sat May 2 00:39:04 2009 From: luis.moreira at ntlworld.com (luis.moreira at ntlworld.com) Date: Sat, 2 May 2009 7:39:04 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Hi Travis, The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. The issues I still have is the errors after that. Do you have any idea what can be causing this errors? _______________________________________________________________________________ conftest.c: In function 'main': conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) conftest.c:8: error: (Each undeclared identifier is reported only once conftest.c:8: error: for each function it appears in.) conftest.c:8: error: expected ')' before string constant conftest.c:8: warning: format not a string literal and no format arguments ./configure: line 21462: ./conftest: No such file or directory ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands ------------------------------------------------------------------------------- I don't know what happened to my previous post, it as not showed up in the list. Best Regards Luis From tjarvi at qbang.org Sat May 2 07:30:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 07:30:04 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> References: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Message-ID: On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > Hi Travis, > The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. > The issues I still have is the errors after that. Do you have any idea what can be causing this errors? > > _______________________________________________________________________________ > conftest.c: In function 'main': > conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) > conftest.c:8: error: (Each undeclared identifier is reported only once > conftest.c:8: error: for each function it appears in.) > conftest.c:8: error: expected ')' before string constant > conftest.c:8: warning: format not a string literal and no format arguments > ./configure: line 21462: ./conftest: No such file or directory > ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: config.h is unchanged > config.status: executing depfiles commands > ------------------------------------------------------------------------------- > > This was corrected in CVS. I think you can just do the following in the top directory: cvs login: (pw is mousy) cvs update That will get the current fixes. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sat May 2 16:14:50 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sat, 02 May 2009 23:14:50 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FCC5DA.6000700@ntlworld.com> Trent Jarvi wrote: > > > On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > >> Hi Travis, >> The problem with the Makefile is not a problem,When I run ./configure >> I make a new Makefile with the same data in it, hence what I just >> modified is removed. >> The issues I still have is the errors after that. Do you have any >> idea what can be causing this errors? >> >> _______________________________________________________________________________ >> >> conftest.c: In function 'main': >> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >> function) >> conftest.c:8: error: (Each undeclared identifier is reported only once >> conftest.c:8: error: for each function it appears in.) >> conftest.c:8: error: expected ')' before string constant >> conftest.c:8: warning: format not a string literal and no format >> arguments >> ./configure: line 21462: ./conftest: No such file or directory >> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >> expected >> configure: creating ./config.status >> config.status: creating Makefile >> config.status: creating config.h >> config.status: config.h is unchanged >> config.status: executing depfiles commands >> ------------------------------------------------------------------------------- >> >> >> > > This was corrected in CVS. I think you can just do the following in > the top directory: > > cvs login: (pw is mousy) > cvs update > > That will get the current fixes. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, apologies for the mix-up of your name. I managed to get further on by updating CVS, the configure command gets to the end without any errors, it still warns me that it is confused about where to find the jni_md.h but I just edited the Makefile and sorted that out. I then run make, with no parameters following the instructions on the Wiki, but that generated a few more errors: ----------------------------------------------------------------------------------------------------------------------- gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. -I/usr/lib/jvm/java-6-openjdk/include /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' undeclared (first use in this function) /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared identifier is reported only once /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each function it appears in.) libtool: link: `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 ----------------------------------------------------------------------------------------------------------------------- Another question I have is, in which folder will the .so files be placed after make finishes? thank you very much for your help. Best Regards Luis From tjarvi at qbang.org Sat May 2 19:27:08 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 19:27:08 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FCC5DA.6000700@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> Message-ID: On Sat, 2 May 2009, Luis Moreira wrote: > Trent Jarvi wrote: >> >> >> On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: >> >>> Hi Travis, >>> The problem with the Makefile is not a problem,When I run ./configure >>> I make a new Makefile with the same data in it, hence what I just >>> modified is removed. >>> The issues I still have is the errors after that. Do you have any >>> idea what can be causing this errors? >>> >>> _______________________________________________________________________________ >>> >>> conftest.c: In function 'main': >>> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >>> function) >>> conftest.c:8: error: (Each undeclared identifier is reported only once >>> conftest.c:8: error: for each function it appears in.) >>> conftest.c:8: error: expected ')' before string constant >>> conftest.c:8: warning: format not a string literal and no format >>> arguments >>> ./configure: line 21462: ./conftest: No such file or directory >>> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >>> expected >>> configure: creating ./config.status >>> config.status: creating Makefile >>> config.status: creating config.h >>> config.status: config.h is unchanged >>> config.status: executing depfiles commands >>> ------------------------------------------------------------------------------- >>> >>> >>> >> >> This was corrected in CVS. I think you can just do the following in >> the top directory: >> >> cvs login: (pw is mousy) >> cvs update >> >> That will get the current fixes. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > apologies for the mix-up of your name. > I managed to get further on by updating CVS, the configure command gets > to the end without any errors, it still warns me that it is confused > about where to find the jni_md.h but I just edited the Makefile and > sorted that out. > I then run make, with no parameters following the instructions on the > Wiki, but that generated a few more errors: > ----------------------------------------------------------------------------------------------------------------------- > > gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. > -I/usr/lib/jvm/java-6-openjdk/include > /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE > -D_BSD_SOURCE -D__need_timespec -c > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o > /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' > undeclared (first use in this function) > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared > identifier is reported only once > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each > function it appears in.) > libtool: link: > `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a > valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 > ----------------------------------------------------------------------------------------------------------------------- > > Another question I have is, in which folder will the .so files be placed > after make finishes? > > thank you very much for your help. > Ah when you do cvs update pass the -Pd option cvs update -Pd Also, when you run configure, use --disable-PRINTER to only build the serial support. It will make things easier. --disable-LOCKFILES will also be easier to get going until you want to learn about how to prevent multiple applications from reading the same serial port. The link for debugging will describe where the files go. By default, it will install in the JRE/JDK under jre/lib/ext (the jar file) jre/lib/i386 (the .so file) Those are on the proper paths when you use the sun or ibm jdk. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sun May 3 01:30:43 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sun, 03 May 2009 08:30:43 +0100 Subject: [Rxtx] First use of RXTX package In-Reply-To: References: <49FCC5DA.6000700@ntlworld.com> Message-ID: <49FD4823.5080204@ntlworld.com> Ah > > when you do cvs update pass the -Pd option > > cvs update -Pd > > Also, when you run configure, use --disable-PRINTER to only build the > serial support. It will make things easier. --disable-LOCKFILES will > also be easier to get going until you want to learn about how to > prevent multiple applications from reading the same serial port. > > The link for debugging will describe where the files go. By default, > it will install in the JRE/JDK under > > jre/lib/ext (the jar file) > jre/lib/i386 (the .so file) > > Those are on the proper paths when you use the sun or ibm jdk. > > http://rxtx.qbang.org/wiki/index.php/Trouble_shooting > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, It as done it! I think this instructions you gave me should be on the Wiki, I can write them for you if you like. Also on the Wiki when you describe the three methods of installing the RxTx package it is confusing because as far as I can see, you always have to do method 1 or the .so files will not be generated(is this correct?). Then you can if you like change the location with method 1 & 2. Is it possible to modify the .la file to point to different directories for installation and then you can decide where to place the files? In a way I have learned quite a lot about Linux by having to struggle, with your help, to find solutions to the problems I encountered (I am still very new to Linux), but maybe we need to log these problems somewhere to make it less of a struggle for others like me. I have used the PortLister example to test it and it came up with my USB to dual Serial adaptor Ports. I will now explore the RxTx package, before I tackle the windows installation, I will let you know of my experience. Thank you for all your Help. Best Regards Luis From tjarvi at qbang.org Sun May 3 10:37:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 3 May 2009 10:37:50 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FD4823.5080204@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> <49FD4823.5080204@ntlworld.com> Message-ID: On Sun, 3 May 2009, Luis Moreira wrote: > Ah >> >> when you do cvs update pass the -Pd option >> >> cvs update -Pd >> >> Also, when you run configure, use --disable-PRINTER to only build the >> serial support. It will make things easier. --disable-LOCKFILES will >> also be easier to get going until you want to learn about how to >> prevent multiple applications from reading the same serial port. >> >> The link for debugging will describe where the files go. By default, >> it will install in the JRE/JDK under >> >> jre/lib/ext (the jar file) >> jre/lib/i386 (the .so file) >> >> Those are on the proper paths when you use the sun or ibm jdk. >> >> http://rxtx.qbang.org/wiki/index.php/Trouble_shooting >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > It as done it! > I think this instructions you gave me should be on the Wiki, I can write > them for you if you like. Also on the Wiki when you describe the three > methods of installing the RxTx package it is confusing because as far > as I can see, you always have to do method 1 or the .so files will not > be generated(is this correct?). Then you can if you like change the > location with method 1 & 2. Is it possible to modify the .la file to > point to different directories for installation and then you can decide > where to place the files? > In a way I have learned quite a lot about Linux by having to struggle, > with your help, to find solutions to the problems I encountered (I am > still very new to Linux), but maybe we need to log these problems > somewhere to make it less of a struggle for others like me. > > I have used the PortLister example to test it and it came up with my USB > to dual Serial adaptor Ports. > > I will now explore the RxTx package, before I tackle the windows > installation, I will let you know of my experience. > > Thank you for all your Help. > Hi Luis, The locations suggested for first time configuration could be documented in a new wiki page explaining that this is not the recommended general workflow but does help new users that are not worried about having rxtx installed into the JRE. For a professional environment, the user would want to follow the workflow currently on the wiki and keep their JRE clean. Often the user will not be able to add libraries to the JRE and will need to use their home directory or a sandbox. Feel free to add information to the wiki. I'd suggest creating comment in the current page and have the comment link to what worked for you as a first time user new to Linux. You can create a new page with your comments. In the long term, we will be working on an autoinstaller that works over the web. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Mon May 4 09:15:40 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Mon, 04 May 2009 16:15:40 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FF069C.8040406@ntlworld.com> Hi Trent, I have now installed the package on my 64 bit machine and when I run my program I get errors on the attachment. I know it as something to do with the architecture of my system but I can no figure out how to fix it. I have built it from source again, I did not transfer the files from machine to machine. can you please put me in the right direction. Thank you very much for your help. Best Regards Luis -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshoot.png Type: image/png Size: 25753 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090504/141ab5dc/attachment-0012.png From johnny.luong at trustcommerce.com Mon May 4 11:57:08 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 04 May 2009 10:57:08 -0700 Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FF069C.8040406@ntlworld.com> References: <49FF069C.8040406@ntlworld.com> Message-ID: <49FF2C74.90805@trustcommerce.com> Luis Moreira wrote: > Hi Trent, > I have now installed the package on my 64 bit machine and when I run my > program I get errors on the attachment. I know it as something to do > with the architecture of my system but I can no figure out how to fix > it. I have built it from source again, I did not transfer the files from > machine to machine. > can you please put me in the right direction. > Thank you very much for your help. > Best Regards > Luis > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Hi, Does running it on a 64-bit JVM help? Your host environment might be building objects for a 64-bit environment unless you did a cross-compile... -- you can find out by doing something like the following: johnny at spike:~$ java -version java version "1.6.0_0" OpenJDK Runtime Environment (build 1.6.0_0-b11) OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode) johnny at spike:~$ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) -Johnny From huangdongkai at gmail.com Wed May 6 11:06:06 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 01:06:06 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. Message-ID: Dear all, I recompile the rxtxSerial source code by MinGW32 and compile success. But when I run my Application which use rxtxSerial.dll to communicate with serial port, a runtime exception happened and application crash. I have no idea why it can not work, beacuse i have not change any source code of rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I have missed when compile the source code on Window NT? Here below is the output error massage. # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, tid=1360 # # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing windows-x86) # Problematic frame: # V [jvm.dll+0x1b6824] # # An error report file with more information is saved as: # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/32c1e699/attachment-0010.html From tjarvi at qbang.org Wed May 6 20:04:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 May 2009 20:04:10 -0600 (MDT) Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: On Thu, 7 May 2009, dongkai huang wrote: > Dear all, > ????? I recompile the rxtxSerial source code by MinGW32 and compile success. > But when I run my Application which use rxtxSerial.dll to communicate with > serial port, a runtime exception happened and application crash.? I have no > idea why it can not work, beacuse i have not change any source code of > rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I > have missed when compile the source code on Window NT? Here below is the > output error massage. > # > # An unexpected error has been detected by Java Runtime Environment: > # > #? EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, > tid=1360 > # > # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing > windows-x86) > > # Problematic frame: > # V? [jvm.dll+0x1b6824] > # > # An error report file with more information is saved as: > # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log > # > # If you would like to submit a bug report, please visit: > #?? http://java.sun.com/webapps/bugreport/crash.jsp > # > > > Hi Dongkai Could you explain how you compiled rxtx with mingw? Did you run configure? Was the compiler native or a cross compiler (like compiling on Linux for Windows)? Is the crash happening when you first open the port or is it happening randomly later on? -- Trent Jarvi tjarvi at qbang.org From huangdongkai at gmail.com Wed May 6 20:48:56 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 10:48:56 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Hi Trent, I was followed the step on INSTALL file, did not run the configure, I used the Makefile.mingw32 which include on the source code package, and only change some path( jdk home path etc.). And I use the native compiler on Windows. The crash happened on I call the getPortIdentifiers() every time. On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Dear all, >> I recompile the rxtxSerial source code by MinGW32 and compile >> success. >> But when I run my Application which use rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and application crash. I have >> no >> idea why it can not work, beacuse i have not change any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing >> I >> have missed when compile the source code on Window NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is saved as: >> # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> > Hi Dongkai > > Could you explain how you compiled rxtx with mingw? Did you run configure? > Was the compiler native or a cross compiler (like compiling on Linux for > Windows)? > > Is the crash happening when you first open the port or is it happening > randomly later on? > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/733eded5/attachment-0010.html From m.j.tandy at warwick.ac.uk Thu May 7 10:39:12 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 7 May 2009 17:39:12 +0100 Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. Message-ID: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> I've encountered a bug in how XON/XOFF are handled on Windows. The symptoms were: 1. XON/XOFF from device to PC did not stop transmission. 2. XON/XOFF characters were present in data read from serial port input stream, when it was expected that they would be stripped out. 3. Investigation with SysInternals PortMon revealed the following configuration when using rxtx: 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 while HyperTerminal, which did not have the same problems as me, produced the following: 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 In other words, the problem is that, in addition to being told to use XON/XOFF flow control, the computer has to explicitly be told which characters to use for 'XON' and 'XOFF'. This part of the configuration was being missed out. I got the latest rxtx source from CVS, and identified the problem as an omission in the 'init_termios' function of 'termios.c', which configures the unix/termios 'c_cc' (control characters) data structure - but omits to configure the VSTART and VSTOP control characters. Later, the termios c_cc data structure is translated (by termios_to_DCB) into a data structure named 'DCB', which is passed to the windows serial port configuration interface. By adding two lines defining the standard XON/XOFF characters to the function init_termios, the bug is fixed. A patch doing this is attached. Thanks, Michael Tandy -------------- next part -------------- A non-text attachment was scrubbed... Name: xon-xoff.diff Type: application/octet-stream Size: 667 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/159c0dcc/attachment-0009.obj From tjarvi at qbang.org Thu May 7 17:57:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 May 2009 17:57:28 -0600 (MDT) Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. In-Reply-To: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> References: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> Message-ID: On Thu, 7 May 2009, Michael Tandy wrote: > I've encountered a bug in how XON/XOFF are handled on Windows. > > The symptoms were: > 1. XON/XOFF from device to PC did not stop transmission. > 2. XON/XOFF characters were present in data read from serial port > input stream, when it was expected that they would be stripped out. > 3. Investigation with SysInternals PortMon revealed the following > configuration when using rxtx: > > 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 > BRK:0 EVT:a XON:0 XOFF:0 > > while HyperTerminal, which did not have the same problems as me, > produced the following: > > 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 > > In other words, the problem is that, in addition to being told to use > XON/XOFF flow control, the computer has to explicitly be told which > characters to use for 'XON' and 'XOFF'. This part of the configuration > was being missed out. > > I got the latest rxtx source from CVS, and identified the problem as > an omission in the 'init_termios' function of 'termios.c', which > configures the unix/termios 'c_cc' (control characters) data structure > - but omits to configure the VSTART and VSTOP control characters. > Later, the termios c_cc data structure is translated (by > termios_to_DCB) into a data structure named 'DCB', which is passed to > the windows serial port configuration interface. > > By adding two lines defining the standard XON/XOFF characters to the > function init_termios, the bug is fixed. A patch doing this is > attached. > Thanks Michael, Good timing. I plan on releasing rxtx-2.2 this coming Sunday. -- Trent Jarvi tjarvi at qbang.org From wjr at weru.ksu.edu Fri May 8 11:38:29 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Fri, 08 May 2009 12:38:29 -0500 Subject: [Rxtx] swing jfilechooser lockup Message-ID: <4A046E15.6010907@weru.ksu.edu> Hi, I wrote a small swing app to download images from an industrial camera. I used the two way serial sample code as a starting point. The app works fine EXCEPT for a call to jfilechooser. After I open the comm port and then try to change the output directory or log file, the jfilechooser winds up trying to unpark (note, parking is not something I'm really familiar with) and doesn't. If I try to change the file or directory before I start the comm port, it works. If I click on menu items that don't call jfilechooser, everything is OK. If I try closing the comm port and then try to create a jfilechooser, it locks up. There is obviously some sort of deadlock here because the awt thread starts waiting on something but it's not clear what. I haven't gone thru the rxtx code yet because it's not in the file structure that netbeans wants for debugging purposes. However, debugging code that I don't have a clear idea of what it is supposed to do is not my idea of a good time. Does anyone have any ideas on what is going on here? Thanks, wjr From Bob_Jacobsen at lbl.gov Fri May 8 14:48:25 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Fri, 8 May 2009 13:48:25 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A046E15.6010907@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> Message-ID: At 12:38 PM -0500 5/8/09, Bill Rust wrote: >Hi, > >I wrote a small swing app to download images from an industrial camera. >I used the two way serial sample code as a starting point. The app works >fine EXCEPT for a call to jfilechooser. After I open the comm port and >then try to change the output directory or log file, the jfilechooser >winds up trying to unpark (note, parking is not something I'm really >familiar with) and doesn't. If I try to change the file or directory >before I start the comm port, it works. If I click on menu items that >don't call jfilechooser, everything is OK. If I try closing the comm >port and then try to create a jfilechooser, it locks up. There is >obviously some sort of deadlock here because the awt thread starts >waiting on something but it's not clear what. I haven't gone thru the >rxtx code yet because it's not in the file structure that netbeans wants >for debugging purposes. However, debugging code that I don't have a >clear idea of what it is supposed to do is not my idea of a good time. What is the threading structure of your code? The various high-function Swing components, such as JFileChooser, are notorious for doing Really Bad Stuff when invoked from off the Swing thread. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From bschlining at gmail.com Fri May 8 15:08:50 2009 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 8 May 2009 14:08:50 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: Bob's probably right...take look at javax.swing.SwingUtilites for the workaround to get your swing stuff invoked on the EventDispatchThread (EDT). Some swing-methods do work when called outside of the EDT, but just to be safe, do your creation and swing calls on the EDT. It's really simple, here's an example of a synchronous call. // Here's how to run stuff on the EDT from a different thread SwingUtilities.invokeAndWait(new Runnable() { public void run() { JFileChooser fc; // create, setup, show your filechooser // Get the result from the filechooser } }); To do a asynchronous call use SwingUtilities.invokeLater > >I wrote a small swing app to download images from an industrial camera. > >I used the two way serial sample code as a starting point. The app works > >fine EXCEPT for a call to jfilechooser. After I open the comm port and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090508/c21c2127/attachment-0008.html From tod at todbot.com Fri May 8 16:27:12 2009 From: tod at todbot.com (Tod E. Kurt) Date: Fri, 8 May 2009 15:27:12 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> This is the exact technique I use to let the user choose which serial port to use on startup. Here's a method I've got in many of my sketches: void choosePort() { String portlist[] = Serial.list(); String port = null; javax.swing.SwingUtilities.invokeLater(new Runnable() { public void run() { try { String port = (String) javax.swing.JOptionPane.showInputDialog( null, "Select Serial Port", "MySuperSketch", javax.swing.JOptionPane.QUESTION_MESSAGE, null, portlist, null); if( port == null ) { javax.swing.JOptionPane.showMessageDialog(null, "No port chosen, goodbye"); System.exit(1); } serialPort = port; } catch (Exception e) { e.printStackTrace(); } } } ); } On May 8, 2009, at 2:08 p, Brian Schlining wrote: > Bob's probably right...take look at javax.swing.SwingUtilites for > the workaround to get your swing stuff invoked on the > EventDispatchThread (EDT). Some swing-methods do work when called > outside of the EDT, but just to be safe, do your creation and swing > calls on the EDT. It's really simple, here's an example of a > synchronous call. > > // Here's how to run stuff on the EDT from a different thread > SwingUtilities.invokeAndWait(new Runnable() { > public void run() { > JFileChooser fc; // create, setup, show your filechooser > // Get the result from the filechooser > } > }); > > To do a asynchronous call use SwingUtilities.invokeLater > > > >I wrote a small swing app to download images from an industrial > camera. > >I used the two way serial sample code as a starting point. The app > works > >fine EXCEPT for a call to jfilechooser. After I open the comm port > and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From huangdongkai at gmail.com Sat May 9 04:46:22 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Sat, 9 May 2009 18:46:22 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Dear Trent, After I intsall the ming32-cross compile to compile the rxtxSerial.dll and testing, i found the same problem still exist. I am not sure my compiler version is the same as your's. Could you tell me the way you can success compile rxtx-2.1-7r2 release source code? Thanks for you kindly help. On Fri, May 8, 2009 at 8:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Hi Trent, >> The attach is the Make file I use to compile the rxtx. >> >> On Thu, May 7, 2009 at 10:48 AM, dongkai huang >> wrote: >> Hi Trent, >> I was followed the step on INSTALL file, did not run the >> configure, I used the Makefile.mingw32 which include on the >> source code package, and only change some path( jdk home path >> etc.). And I use the native compiler on Windows. >> The crash happened on I call the getPortIdentifiers() >> every time. >> >> On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: >> >> >> On Thu, 7 May 2009, dongkai huang wrote: >> >> Dear all, >> I recompile the rxtxSerial source code by >> MinGW32 and compile success. >> But when I run my Application which use >> rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and >> application crash. I have no >> idea why it can not work, beacuse i have not change >> any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source >> code. Did some thing I >> have missed when compile the source code on Window >> NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java >> Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at >> pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 >> mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is >> saved as: >> # >> D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please >> visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> >> Hi Dongkai >> >> Could you explain how you compiled rxtx with mingw? Did you run >> configure? Was the compiler native or a cross compiler (like >> compiling on Linux for Windows)? >> >> Is the crash happening when you first open the port or is it >> happening randomly later on? >> >> > Thanks Dongkai > > I'll look at your Makefile tomorrow. Which version of mingw was this? > > I suspect there is a problem with that makefile. I usually built that > version of rxtx for windows with a mingw32 cross compiler using the > configure script. > > The configure script may well work for you if you have a cygwin environment > with mingw instead of gcc. I'll take a look at what is different. > > -- > > Trent Jarvi > tjarvi at qbang.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090509/b729c429/attachment-0008.html From wjr at weru.ksu.edu Wed May 13 15:50:30 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Wed, 13 May 2009 16:50:30 -0500 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> Message-ID: <4A0B40A6.5070204@weru.ksu.edu> Tod's solution misses the point. He is picking and opening the serial port. That's the step before where my problem occurs. To recap: 1. I have a simple java swing app. 2. On the menu bar, there is the standard set, file, etc., of jmenu's. Under file, there is a jmenuitem, logfileopen, which pops up a jfilechooser to select a logfile and another jmenuitem, setprefix, which pops up a jdialog to allow the user to type in a file name prefix for downloaded images. 3. There is another jmenuitem that starts the commport running. 4. When logfileopen is pressed before the commport is started, it works. 5. When logfileopen is pressed after the commport is started, it hangs. 6. setprefix works whether or not the commport is started. 7. portIdentifier.open starts a thread that goes into a native method, RXTXPort.eventLoop, and never returns. 8. java.sun bugs has a bug report, 6741890, that is similar but their workaround doesn't. 9. When it locks up, there is a swing-shell thread that appears to be down in some native libraries, winshellfolder2 10. The awt-eventQ thread is unblocked but in code that says its parked. If you have anymore ideas, I'd really appreciate them. wjr Tod E. Kurt wrote: > This is the exact technique I use to let the user choose which serial > port to use on startup. Here's a method I've got in many of my sketches: > > void choosePort() { > String portlist[] = Serial.list(); > String port = null; > javax.swing.SwingUtilities.invokeLater(new Runnable() { > public void run() { > try { > String port = (String) javax.swing.JOptionPane.showInputDialog( > null, > "Select Serial Port", > "MySuperSketch", > javax.swing.JOptionPane.QUESTION_MESSAGE, > null, portlist, null); > if( port == null ) { > javax.swing.JOptionPane.showMessageDialog(null, "No port > chosen, goodbye"); > System.exit(1); > } > serialPort = port; > } > catch (Exception e) { > e.printStackTrace(); > } > } > } ); > } > > > On May 8, 2009, at 2:08 p, Brian Schlining wrote: > >> Bob's probably right...take look at javax.swing.SwingUtilites for the >> workaround to get your swing stuff invoked on the EventDispatchThread >> (EDT). Some swing-methods do work when called outside of the EDT, but >> just to be safe, do your creation and swing calls on the EDT. It's >> really simple, here's an example of a synchronous call. >> >> // Here's how to run stuff on the EDT from a different thread >> SwingUtilities.invokeAndWait(new Runnable() { >> public void run() { >> JFileChooser fc; // create, setup, show your filechooser >> // Get the result from the filechooser >> } >> }); >> >> To do a asynchronous call use SwingUtilities.invokeLater >> >> >> >I wrote a small swing app to download images from an industrial camera. >> >I used the two way serial sample code as a starting point. The app works >> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >> >then try to change the output directory or log file, the jfilechooser >> >winds up trying to unpark (note, parking is not something I'm really >> >familiar with) and doesn't. >> What is the threading structure of your code? >> >> The various high-function Swing components, such as JFileChooser, are >> notorious for doing Really Bad Stuff when invoked from off the Swing >> thread. >> >> Bob >> -- >> Bob Jacobsen, UC Berkeley >> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >> JacobsenRG >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -- >> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >> Brian Schlining >> bschlining at gmail.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx From m.j.tandy at warwick.ac.uk Wed May 13 16:42:24 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 13 May 2009 23:42:24 +0100 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A0B40A6.5070204@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> <4A0B40A6.5070204@weru.ksu.edu> Message-ID: <302aa0340905131542i601ec3f1w3b0b5879c23f8eca@mail.gmail.com> Perhaps you could post your program, or an excerpt of it sufficient to demonstrate the problem you're having, for us to have a look at? 2009/5/13 Bill Rust : > Tod's solution misses the point. He is picking and opening the serial > port. That's the step before where my problem occurs. > > To recap: > > 1. I have a simple java swing app. > 2. On the menu bar, there is the standard set, file, etc., of jmenu's. > Under file, there is a jmenuitem, logfileopen, which pops up a > jfilechooser to select a logfile and another jmenuitem, setprefix, which > pops up a jdialog to allow the user to type in a file name prefix for > downloaded images. > 3. There is another jmenuitem that starts the commport running. > 4. When logfileopen is pressed before the commport is started, it works. > 5. When logfileopen is pressed after the commport is started, it hangs. > 6. setprefix works whether or not the commport is started. > 7. portIdentifier.open starts a thread that goes into a native > method, ? ? ? ? ? ? ? ? ? ? ? ? RXTXPort.eventLoop, and never returns. > 8. java.sun bugs has a bug report, 6741890, that is similar but > their ? ? ? ? ? ? ? ? ? workaround doesn't. > 9. When it locks up, there is a swing-shell thread that appears to be > ? ? ? ?down in some native libraries, winshellfolder2 > 10. The awt-eventQ thread is unblocked but in code that says its parked. > > If you have anymore ideas, I'd really appreciate them. > > wjr > > Tod E. Kurt wrote: >> This is the exact technique I use to let the user choose which serial >> port to use on startup. ?Here's a method I've got in many of my sketches: >> >> void choosePort() { >> ? String portlist[] = Serial.list(); >> ? String port = null; >> ? javax.swing.SwingUtilities.invokeLater(new Runnable() { >> ? ? public void run() { >> ? ? ? try { >> ? ? ? ? String port = (String) javax.swing.JOptionPane.showInputDialog( >> null, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Select Serial Port", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "MySuperSketch", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? javax.swing.JOptionPane.QUESTION_MESSAGE, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? null, portlist, null); >> ? ? ? ? if( port == null ) ?{ >> ? ? ? ? ? javax.swing.JOptionPane.showMessageDialog(null, "No port >> chosen, goodbye"); >> ? ? ? ? ? System.exit(1); >> ? ? ? ? } >> ? ? ? ? serialPort = port; >> ? ? ? } >> ? ? ? catch (Exception e) { >> ? ? ? ? e.printStackTrace(); >> ? ? ? } >> ? ? } >> ? } ); >> } >> >> >> On May 8, 2009, at 2:08 p, Brian Schlining wrote: >> >>> Bob's probably right...take look at javax.swing.SwingUtilites for the >>> workaround to get your swing stuff invoked on the EventDispatchThread >>> (EDT). Some swing-methods do work when called outside of the EDT, but >>> just to be safe, do your creation and swing calls on the EDT. It's >>> really simple, here's an example of a synchronous call. >>> >>> // Here's how to run stuff on the EDT from a different thread >>> SwingUtilities.invokeAndWait(new Runnable() { >>> ? ? ? public void run() { >>> ? ? ? ? ? ?JFileChooser fc; // create, setup, show your filechooser >>> ? ? ? ? ? ?// Get the result from the filechooser >>> ? ? ? } >>> }); >>> >>> To do a asynchronous call use SwingUtilities.invokeLater >>> >>> >>> >I wrote a small swing app to download images from an industrial camera. >>> >I used the two way serial sample code as a starting point. The app works >>> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >>> >then try to change the output directory or log file, the jfilechooser >>> >winds up trying to unpark (note, parking is not something I'm really >>> >familiar with) and doesn't. >>> What is the threading structure of your code? >>> >>> The various high-function Swing components, such as JFileChooser, are >>> notorious for doing Really Bad Stuff when invoked from off the Swing >>> thread. >>> >>> Bob >>> -- >>> Bob Jacobsen, UC Berkeley >>> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >>> JacobsenRG >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >>> -- >>> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >>> Brian Schlining >>> bschlining at gmail.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From m.j.tandy at warwick.ac.uk Thu May 14 03:05:36 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 14 May 2009 10:05:36 +0100 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A0B40A6.5070204@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> <4A0B40A6.5070204@weru.ksu.edu> Message-ID: <302aa0340905140205p6ceb5a9br24e00a50e9cafa5@mail.gmail.com> Java has a built in deadlock detection utility; run your program from the command line, then (on windows) press Ctrl+Break (On Linux, Ctrl+\ does the trick I'm told). That should produce status information and a stack trace for every running thread, including locks held and locks waited on. Maybe that would contain enough information for you to work out what's locking what? 2009/5/13 Bill Rust : > Tod's solution misses the point. He is picking and opening the serial > port. That's the step before where my problem occurs. > > To recap: > > 1. I have a simple java swing app. > 2. On the menu bar, there is the standard set, file, etc., of jmenu's. > Under file, there is a jmenuitem, logfileopen, which pops up a > jfilechooser to select a logfile and another jmenuitem, setprefix, which > pops up a jdialog to allow the user to type in a file name prefix for > downloaded images. > 3. There is another jmenuitem that starts the commport running. > 4. When logfileopen is pressed before the commport is started, it works. > 5. When logfileopen is pressed after the commport is started, it hangs. > 6. setprefix works whether or not the commport is started. > 7. portIdentifier.open starts a thread that goes into a native > method, ? ? ? ? ? ? ? ? ? ? ? ? RXTXPort.eventLoop, and never returns. > 8. java.sun bugs has a bug report, 6741890, that is similar but > their ? ? ? ? ? ? ? ? ? workaround doesn't. > 9. When it locks up, there is a swing-shell thread that appears to be > ? ? ? ?down in some native libraries, winshellfolder2 > 10. The awt-eventQ thread is unblocked but in code that says its parked. > > If you have anymore ideas, I'd really appreciate them. > > wjr > > Tod E. Kurt wrote: >> This is the exact technique I use to let the user choose which serial >> port to use on startup. ?Here's a method I've got in many of my sketches: >> >> void choosePort() { >> ? String portlist[] = Serial.list(); >> ? String port = null; >> ? javax.swing.SwingUtilities.invokeLater(new Runnable() { >> ? ? public void run() { >> ? ? ? try { >> ? ? ? ? String port = (String) javax.swing.JOptionPane.showInputDialog( >> null, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Select Serial Port", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "MySuperSketch", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? javax.swing.JOptionPane.QUESTION_MESSAGE, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? null, portlist, null); >> ? ? ? ? if( port == null ) ?{ >> ? ? ? ? ? javax.swing.JOptionPane.showMessageDialog(null, "No port >> chosen, goodbye"); >> ? ? ? ? ? System.exit(1); >> ? ? ? ? } >> ? ? ? ? serialPort = port; >> ? ? ? } >> ? ? ? catch (Exception e) { >> ? ? ? ? e.printStackTrace(); >> ? ? ? } >> ? ? } >> ? } ); >> } >> >> >> On May 8, 2009, at 2:08 p, Brian Schlining wrote: >> >>> Bob's probably right...take look at javax.swing.SwingUtilites for the >>> workaround to get your swing stuff invoked on the EventDispatchThread >>> (EDT). Some swing-methods do work when called outside of the EDT, but >>> just to be safe, do your creation and swing calls on the EDT. It's >>> really simple, here's an example of a synchronous call. >>> >>> // Here's how to run stuff on the EDT from a different thread >>> SwingUtilities.invokeAndWait(new Runnable() { >>> ? ? ? public void run() { >>> ? ? ? ? ? ?JFileChooser fc; // create, setup, show your filechooser >>> ? ? ? ? ? ?// Get the result from the filechooser >>> ? ? ? } >>> }); >>> >>> To do a asynchronous call use SwingUtilities.invokeLater >>> >>> >>> >I wrote a small swing app to download images from an industrial camera. >>> >I used the two way serial sample code as a starting point. The app works >>> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >>> >then try to change the output directory or log file, the jfilechooser >>> >winds up trying to unpark (note, parking is not something I'm really >>> >familiar with) and doesn't. >>> What is the threading structure of your code? >>> >>> The various high-function Swing components, such as JFileChooser, are >>> notorious for doing Really Bad Stuff when invoked from off the Swing >>> thread. >>> >>> Bob >>> -- >>> Bob Jacobsen, UC Berkeley >>> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >>> JacobsenRG >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >>> -- >>> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >>> Brian Schlining >>> bschlining at gmail.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From cowwoc at bbs.darktech.org Fri May 15 07:18:29 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 09:18:29 -0400 Subject: [Rxtx] InputStream timeouts Message-ID: <4A0D6BA5.8020209@bbs.darktech.org> Why does InputStream.read() return -1 on timeout instead of throwing InterruptedIOException which has existed specifically for this purpose since JDK 1.0? Sockets throw SocketTimeoutException which extends InterruptedIOException. I suspect that this logic confuses BufferedInputStream as well as end-users. Can we introduce this change along with the other timeout-related changes? Gili From Steffen.DETTMER at ingenico.com Fri May 15 07:36:19 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 15 May 2009 15:36:19 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0D6BA5.8020209@bbs.darktech.org> References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <20090515133619.GC17036@elberon.bln.de.ingenico.com> * cowwoc wrote on Fri, May 15, 2009 at 09:18 -0400: > Why does InputStream.read() return -1 on timeout shouldn't it block and only avialable() should care about timeouts? That is how I understand `This method blocks until input data is available' from: http://java.sun.com/j2se/1.5.0/docs/api/java/io/InputStream.html#read() public abstract int read() throws IOException Reads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. A subclass must provide an implementation of this method. Returns: the next byte of data, or -1 if the end of the stream is reached. Throws: IOException - if an I/O error occurs. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Fri May 15 08:22:19 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 15 May 2009 17:22:19 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: >From the javadoc for InputStream: "If no byte is available because the end of the stream has been reached, the value -1 is returned." Since character timeout is not an indication of EOF condition I guess one could argue that 0 should be returned in case of timeout. On the other hand one could also argue that since no data was available (if it timed out) the serial port input stream was at the end of stream (albeit possibly temporarily only). Further the javadoc seems to forbid the return value 0 for Inputstream.read(): " This method blocks until input data is available, the end of the stream is detected, or an exception is thrown." So it can return n >= 1 , -1 or throw an exception. InputStream.read(byte[]) can return 0 but for consistency the options with the other read methods the return value for timeout needs to be -1 or an exception. It goes against my grain to think that I get an exception when I've set up a timeout and I am thus expecting a timeout to happen sometimes. So it is not an exceptional case but expected situation in which case a special return value is philosophically speaking more appropriate. So I'm against changing this behavior. I expect a lot of code depend on the -1 or at least on not getting an exception when a timeout occurs. In any case if an exception were to be thrown it should *not* be InterruptedIOException. >From the javadoc for InterruptedIOException: "An InterruptedIOException is thrown to indicate that an input or output transfer has been terminated because the thread performing it was interrupted. The field bytesTransferred indicates how many bytes were successfully transferred before the interruption occurred" I do not think this matches the case for serial port receive character timeout. I read the javadoc above so that I get this exception when the thread in my code that is performing a read or write operation gets interrupted by Thread.interrupt(). And this is used to handle exactly that case: being able to gracefully and cleanly interrupt threads. my 2 snt worth br Kusti > From: cowwoc > Date: Fri, 15 May 2009 16:18:29 +0300 > To: rxtx > Conversation: [Rxtx] InputStream timeouts > Subject: [Rxtx] InputStream timeouts > > > > Why does InputStream.read() return -1 on timeout instead of > throwing InterruptedIOException which has existed specifically for this > purpose since JDK 1.0? Sockets throw SocketTimeoutException which > extends InterruptedIOException. I suspect that this logic confuses > BufferedInputStream as well as end-users. Can we introduce this change > along with the other timeout-related changes? > > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From cowwoc at bbs.darktech.org Fri May 15 08:35:27 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 10:35:27 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <4A0D7DAF.5030705@bbs.darktech.org> I disagree with your interpretation. Read SocketTimeoutException to see what I mean. InterruptedIOException means the operation was interrupted, not necessarily by way of Thread.interrupt(). Returning 0 in case of timeout sounds wrong to me because it is a legal byte value that could have been read. Returning -1 also sounds wrong to me because this isn't strictly the end of stream. BufferedInputStream and others assume that once you reach the end of stream you will never see more data, ever. As far as I know, the core APIs are written in terms of throwing InterruptedIOException for timeouts. Gili Kustaa Nyholm wrote: > >>From the javadoc for InputStream: > > "If no byte is available because the end of the stream has been reached, the > value -1 is returned." > > > Since character timeout is not an indication of EOF condition I guess one > could argue that 0 should be returned in case of timeout. On the other hand > one could also argue that since no data was available (if it timed out) the > serial port input stream was at the end of stream (albeit possibly > temporarily only). Further the javadoc seems to forbid the return value 0 > for Inputstream.read(): > > " This method blocks until input data is available, the end of the stream is > detected, or an exception is thrown." > > So it can return n >= 1 , -1 or throw an exception. InputStream.read(byte[]) > can return 0 but for consistency the options with the other read methods the > return value for timeout needs to be -1 or an exception. > > It goes against my grain to think that I get an exception when I've set up a > timeout and I am thus expecting a timeout to happen sometimes. So it is not > an exceptional case but expected situation in which case a special return > value is philosophically speaking more appropriate. > > So I'm against changing this behavior. I expect a lot of code depend on the > -1 or at least on not getting an exception when a timeout occurs. > > In any case if an exception were to be thrown it should *not* be > InterruptedIOException. > >>From the javadoc for InterruptedIOException: > > > "An InterruptedIOException is thrown to indicate that an input or output > transfer has been terminated because the thread performing it was > interrupted. The field bytesTransferred indicates how many bytes were > successfully transferred before the interruption occurred" > > I do not think this matches the case for serial port receive character > timeout. I read the javadoc above so that I get this exception when the > thread in my code that is performing a read or write operation gets > interrupted by Thread.interrupt(). And this is used to handle exactly that > case: being able to gracefully and cleanly interrupt threads. > > > > my 2 snt worth br Kusti > > > > >> From: cowwoc >> Date: Fri, 15 May 2009 16:18:29 +0300 >> To: rxtx >> Conversation: [Rxtx] InputStream timeouts >> Subject: [Rxtx] InputStream timeouts >> >> >> >> Why does InputStream.read() return -1 on timeout instead of >> throwing InterruptedIOException which has existed specifically for this >> purpose since JDK 1.0? Sockets throw SocketTimeoutException which >> extends InterruptedIOException. I suspect that this logic confuses >> BufferedInputStream as well as end-users. Can we introduce this change >> along with the other timeout-related changes? >> >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From m.j.tandy at warwick.ac.uk Fri May 15 09:17:36 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Fri, 15 May 2009 16:17:36 +0100 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <302aa0340905150817o39812d7y1b896004a2dcc2ab@mail.gmail.com> > I disagree with your interpretation. Read SocketTimeoutException to see > what I mean. InterruptedIOException means the operation was interrupted, > not necessarily by way of Thread.interrupt(). Strangely enough, the javadoc for InterruptedIOException says: "An InterruptedIOException is thrown to indicate that an input or output transfer has been terminated because the thread performing it was interrupted."[1] But the subclass SocketTimeoutException is used differently - here's an example from sun.net.httpserver.request: /** * block() only called when available==0 and buf is empty */ private synchronized void block () throws IOException { long currtime = server.getTime(); long maxtime = currtime + readTimeout; while (currtime < maxtime) { if (selector.select (readTimeout) == 1) { selector.selectedKeys().clear(); available (); return; } currtime = server.getTime(); } throw new SocketTimeoutException ("no data received"); } So it seems that SocketTimeoutExceptions get thrown not upon thread interruptions, but a certain time after a blocking read is started. [1] http://java.sun.com/javase/6/docs/api/java/io/InterruptedIOException.html From cowwoc at bbs.darktech.org Fri May 15 11:06:53 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 13:06:53 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0DA0F4.9050203@bbs.darktech.org> References: <4A0DA0F4.9050203@bbs.darktech.org> Message-ID: <4A0DA12D.2050303@bbs.darktech.org> Forgot to CC the list. Gili cowwoc wrote: > > "Thread was interrupted" does not necessarily mean > Thread.interrupt(). It just means that the operation (run by the thread) > was interrupted. If you read the beginning sentence for > InterruptedIOException it reads "Signals that an I/O operation has been > interrupted". This says nothing about the thread itself. Michael's > subsequent post about SocketTimeoutException reinforces that point. > > By the way, I think that in general you need to interpret the > Javadoc for core classes in a broader sense than it seems. Older Javadoc > (from version 1.0) used to mention implementation details that were not > necessarily important and limited the applicability of the classes. > Newer documentation tends to go out of its way to avoid mentioning such > implementation detail and I believe that's a good thing. When > InterruptedIOException was written, Thread.interrupt() was probably the > only way to interrupt I/O operations. Nowadays there are others. Sun has > generalized its meaning over time as evident by SocketTimeoutException. > At least, that's my interpretation :) > > Gili > > Kustaa Nyholm wrote: >>> I disagree with your interpretation. Read >>> SocketTimeoutException to >>> see >>> what I mean. InterruptedIOException means the operation was interrupted, >>> not necessarily by way of Thread.interrupt(). >> >> Well SocketTimeoutException javadoc only says, very briefly: >> >> "Signals that a timeout has occurred on a socket read or accept." >> >> So that is not too helpful. But since it is derived from >> InterruptedIOException my interpretation it that they have an 'is-a' >> relationship and InterruptedIOException needs to honor the contract of >> InterruptedIOException which says: >> >> "...because the thread performing it was interrupted." >> >> To me this very specifically talks about interrupting threads with >> Thread.interrupt() >> >> >>> Returning 0 in case of timeout sounds wrong to me because it >>> is a >>> legal >>> byte value that could have been read. >> Agreed, that's what I tried to say. 0 is a legal byte value for read() to >> return so that cannot be used. For read read(byte[]) which returns the >> number of bytes read 0 could be used but there again 0 can be returned >> if 0 >> byte[] size is 0. So there again 0 is not a good option. >> >>> Returning -1 also sounds wrong to >>> me because this isn't strictly the end of stream. >> Like I said, it isn't strictly the end of stream. But also does not >> forbid treating it as (temporary) end of stream. >> >>> BufferedInputStream >>> and others assume that once you reach the end of stream you will never >>> see more data, ever. >> Can you provide a reference for that. >> >>> As far as I know, the core APIs are written in >>> terms of throwing InterruptedIOException for timeouts. >> Would also like to see something to support that. >> >> >> The behavior of throwing an exception on timeout is also a little bit >> problematic, consider: >> >> byte buf[1000]; >> int n=ins.read(buf); >> // do something with the n bytes received >> >> What happens if a timeout occurs before we have received 1000 bytes? >> >> If an exception is thrown then the user of the read() needs to handle >> the bytes received in two places or else those last <1000 bytes are lost. >> A better solution would be to return the bytes received so far and throw >> the exception on the next call (if any). But the main point is that >> neither of these case obviously correct and neither is specified in the >> javadocs. Where as a lot of code that just handles the return value >> of read(byte[]) correctly works without any further ado. >> >> >> >> The main thing is that I think we should not break existing applications, >> which I expect are not handling InterruptedIOException but many of >> which may >> depend on getting back -1 in case of timeouts. >> >> It has been a while since I used the javax.javacomm but I seem to recall >> that it returned -1 and I think this is the defining standard. >> >> I expect most rxtx users are more interested in compatibility and >> stability >> than semantic niceties and improving the API. >> >> br Kusti >> >> >> > From johnny.luong at trustcommerce.com Fri May 15 13:16:15 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Fri, 15 May 2009 12:16:15 -0700 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0DA12D.2050303@bbs.darktech.org> References: <4A0DA0F4.9050203@bbs.darktech.org> <4A0DA12D.2050303@bbs.darktech.org> Message-ID: <4A0DBF7F.50808@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 cowwoc wrote: | Forgot to CC the list. | | Gili | | cowwoc wrote: |> "Thread was interrupted" does not necessarily mean |> Thread.interrupt(). It just means that the operation (run by the thread) |> was interrupted. If you read the beginning sentence for |> InterruptedIOException it reads "Signals that an I/O operation has been |> interrupted". This says nothing about the thread itself. Michael's |> subsequent post about SocketTimeoutException reinforces that point. |> |> By the way, I think that in general you need to interpret the |> Javadoc for core classes in a broader sense than it seems. Older Javadoc |> (from version 1.0) used to mention implementation details that were not |> necessarily important and limited the applicability of the classes. |> Newer documentation tends to go out of its way to avoid mentioning such |> implementation detail and I believe that's a good thing. When |> InterruptedIOException was written, Thread.interrupt() was probably the |> only way to interrupt I/O operations. Nowadays there are others. Sun has |> generalized its meaning over time as evident by SocketTimeoutException. |> At least, that's my interpretation :) |> |> Gili |> |> Kustaa Nyholm wrote: |>>> I disagree with your interpretation. Read |>>> SocketTimeoutException to |>>> see |>>> what I mean. InterruptedIOException means the operation was interrupted, |>>> not necessarily by way of Thread.interrupt(). |>> Well SocketTimeoutException javadoc only says, very briefly: |>> |>> "Signals that a timeout has occurred on a socket read or accept." |>> |>> So that is not too helpful. But since it is derived from |>> InterruptedIOException my interpretation it that they have an 'is-a' |>> relationship and InterruptedIOException needs to honor the contract of |>> InterruptedIOException which says: |>> |>> "...because the thread performing it was interrupted." |>> |>> To me this very specifically talks about interrupting threads with |>> Thread.interrupt() |>> |>> |>>> Returning 0 in case of timeout sounds wrong to me because it |>>> is a |>>> legal |>>> byte value that could have been read. |>> Agreed, that's what I tried to say. 0 is a legal byte value for read() to |>> return so that cannot be used. For read read(byte[]) which returns the |>> number of bytes read 0 could be used but there again 0 can be returned |>> if 0 |>> byte[] size is 0. So there again 0 is not a good option. |>> |>>> Returning -1 also sounds wrong to |>>> me because this isn't strictly the end of stream. |>> Like I said, it isn't strictly the end of stream. But also does not |>> forbid treating it as (temporary) end of stream. |>> |>>> BufferedInputStream |>>> and others assume that once you reach the end of stream you will never |>>> see more data, ever. |>> Can you provide a reference for that. |>> |>>> As far as I know, the core APIs are written in |>>> terms of throwing InterruptedIOException for timeouts. |>> Would also like to see something to support that. |>> |>> |>> The behavior of throwing an exception on timeout is also a little bit |>> problematic, consider: |>> |>> byte buf[1000]; |>> int n=ins.read(buf); |>> // do something with the n bytes received |>> |>> What happens if a timeout occurs before we have received 1000 bytes? |>> |>> If an exception is thrown then the user of the read() needs to handle |>> the bytes received in two places or else those last <1000 bytes are lost. |>> A better solution would be to return the bytes received so far and throw |>> the exception on the next call (if any). But the main point is that |>> neither of these case obviously correct and neither is specified in the |>> javadocs. Where as a lot of code that just handles the return value |>> of read(byte[]) correctly works without any further ado. |>> |>> |>> |>> The main thing is that I think we should not break existing applications, |>> which I expect are not handling InterruptedIOException but many of |>> which may |>> depend on getting back -1 in case of timeouts. |>> |>> It has been a while since I used the javax.javacomm but I seem to recall |>> that it returned -1 and I think this is the defining standard. |>> |>> I expect most rxtx users are more interested in compatibility and |>> stability |>> than semantic niceties and improving the API. |>> |>> br Kusti |>> |>> |>> | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi, Maybe a better approach (improving the API) would be to consider implementing a NIO interface atop the underlying serial communication... ~ if someone desires the existing behavior, then they use a facade that lies atop of the NIO and provide the same quirks associated with it. As I see it, the implementation overrides the general contract of the InputStream to provide for the timeout functionality and it would be somewhat troublesome to expect a user of that API to catch subclasses of IOException. Best, Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoNv38ACgkQnQTBLXttTeWZ+wCeO4CTrI5l+vLPrjHl8fBj7FOL Ft8AnjQ7bXnvMhOlwZdK5CYAuoQeQ9u0 =QAax -----END PGP SIGNATURE----- From luis.moreira at ntlworld.com Sat May 2 00:39:04 2009 From: luis.moreira at ntlworld.com (luis.moreira at ntlworld.com) Date: Sat, 2 May 2009 7:39:04 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Hi Travis, The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. The issues I still have is the errors after that. Do you have any idea what can be causing this errors? _______________________________________________________________________________ conftest.c: In function 'main': conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) conftest.c:8: error: (Each undeclared identifier is reported only once conftest.c:8: error: for each function it appears in.) conftest.c:8: error: expected ')' before string constant conftest.c:8: warning: format not a string literal and no format arguments ./configure: line 21462: ./conftest: No such file or directory ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands ------------------------------------------------------------------------------- I don't know what happened to my previous post, it as not showed up in the list. Best Regards Luis From tjarvi at qbang.org Sat May 2 07:30:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 07:30:04 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> References: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Message-ID: On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > Hi Travis, > The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. > The issues I still have is the errors after that. Do you have any idea what can be causing this errors? > > _______________________________________________________________________________ > conftest.c: In function 'main': > conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) > conftest.c:8: error: (Each undeclared identifier is reported only once > conftest.c:8: error: for each function it appears in.) > conftest.c:8: error: expected ')' before string constant > conftest.c:8: warning: format not a string literal and no format arguments > ./configure: line 21462: ./conftest: No such file or directory > ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: config.h is unchanged > config.status: executing depfiles commands > ------------------------------------------------------------------------------- > > This was corrected in CVS. I think you can just do the following in the top directory: cvs login: (pw is mousy) cvs update That will get the current fixes. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sat May 2 16:14:50 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sat, 02 May 2009 23:14:50 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FCC5DA.6000700@ntlworld.com> Trent Jarvi wrote: > > > On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > >> Hi Travis, >> The problem with the Makefile is not a problem,When I run ./configure >> I make a new Makefile with the same data in it, hence what I just >> modified is removed. >> The issues I still have is the errors after that. Do you have any >> idea what can be causing this errors? >> >> _______________________________________________________________________________ >> >> conftest.c: In function 'main': >> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >> function) >> conftest.c:8: error: (Each undeclared identifier is reported only once >> conftest.c:8: error: for each function it appears in.) >> conftest.c:8: error: expected ')' before string constant >> conftest.c:8: warning: format not a string literal and no format >> arguments >> ./configure: line 21462: ./conftest: No such file or directory >> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >> expected >> configure: creating ./config.status >> config.status: creating Makefile >> config.status: creating config.h >> config.status: config.h is unchanged >> config.status: executing depfiles commands >> ------------------------------------------------------------------------------- >> >> >> > > This was corrected in CVS. I think you can just do the following in > the top directory: > > cvs login: (pw is mousy) > cvs update > > That will get the current fixes. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, apologies for the mix-up of your name. I managed to get further on by updating CVS, the configure command gets to the end without any errors, it still warns me that it is confused about where to find the jni_md.h but I just edited the Makefile and sorted that out. I then run make, with no parameters following the instructions on the Wiki, but that generated a few more errors: ----------------------------------------------------------------------------------------------------------------------- gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. -I/usr/lib/jvm/java-6-openjdk/include /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' undeclared (first use in this function) /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared identifier is reported only once /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each function it appears in.) libtool: link: `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 ----------------------------------------------------------------------------------------------------------------------- Another question I have is, in which folder will the .so files be placed after make finishes? thank you very much for your help. Best Regards Luis From tjarvi at qbang.org Sat May 2 19:27:08 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 19:27:08 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FCC5DA.6000700@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> Message-ID: On Sat, 2 May 2009, Luis Moreira wrote: > Trent Jarvi wrote: >> >> >> On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: >> >>> Hi Travis, >>> The problem with the Makefile is not a problem,When I run ./configure >>> I make a new Makefile with the same data in it, hence what I just >>> modified is removed. >>> The issues I still have is the errors after that. Do you have any >>> idea what can be causing this errors? >>> >>> _______________________________________________________________________________ >>> >>> conftest.c: In function 'main': >>> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >>> function) >>> conftest.c:8: error: (Each undeclared identifier is reported only once >>> conftest.c:8: error: for each function it appears in.) >>> conftest.c:8: error: expected ')' before string constant >>> conftest.c:8: warning: format not a string literal and no format >>> arguments >>> ./configure: line 21462: ./conftest: No such file or directory >>> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >>> expected >>> configure: creating ./config.status >>> config.status: creating Makefile >>> config.status: creating config.h >>> config.status: config.h is unchanged >>> config.status: executing depfiles commands >>> ------------------------------------------------------------------------------- >>> >>> >>> >> >> This was corrected in CVS. I think you can just do the following in >> the top directory: >> >> cvs login: (pw is mousy) >> cvs update >> >> That will get the current fixes. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > apologies for the mix-up of your name. > I managed to get further on by updating CVS, the configure command gets > to the end without any errors, it still warns me that it is confused > about where to find the jni_md.h but I just edited the Makefile and > sorted that out. > I then run make, with no parameters following the instructions on the > Wiki, but that generated a few more errors: > ----------------------------------------------------------------------------------------------------------------------- > > gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. > -I/usr/lib/jvm/java-6-openjdk/include > /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE > -D_BSD_SOURCE -D__need_timespec -c > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o > /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' > undeclared (first use in this function) > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared > identifier is reported only once > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each > function it appears in.) > libtool: link: > `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a > valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 > ----------------------------------------------------------------------------------------------------------------------- > > Another question I have is, in which folder will the .so files be placed > after make finishes? > > thank you very much for your help. > Ah when you do cvs update pass the -Pd option cvs update -Pd Also, when you run configure, use --disable-PRINTER to only build the serial support. It will make things easier. --disable-LOCKFILES will also be easier to get going until you want to learn about how to prevent multiple applications from reading the same serial port. The link for debugging will describe where the files go. By default, it will install in the JRE/JDK under jre/lib/ext (the jar file) jre/lib/i386 (the .so file) Those are on the proper paths when you use the sun or ibm jdk. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sun May 3 01:30:43 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sun, 03 May 2009 08:30:43 +0100 Subject: [Rxtx] First use of RXTX package In-Reply-To: References: <49FCC5DA.6000700@ntlworld.com> Message-ID: <49FD4823.5080204@ntlworld.com> Ah > > when you do cvs update pass the -Pd option > > cvs update -Pd > > Also, when you run configure, use --disable-PRINTER to only build the > serial support. It will make things easier. --disable-LOCKFILES will > also be easier to get going until you want to learn about how to > prevent multiple applications from reading the same serial port. > > The link for debugging will describe where the files go. By default, > it will install in the JRE/JDK under > > jre/lib/ext (the jar file) > jre/lib/i386 (the .so file) > > Those are on the proper paths when you use the sun or ibm jdk. > > http://rxtx.qbang.org/wiki/index.php/Trouble_shooting > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, It as done it! I think this instructions you gave me should be on the Wiki, I can write them for you if you like. Also on the Wiki when you describe the three methods of installing the RxTx package it is confusing because as far as I can see, you always have to do method 1 or the .so files will not be generated(is this correct?). Then you can if you like change the location with method 1 & 2. Is it possible to modify the .la file to point to different directories for installation and then you can decide where to place the files? In a way I have learned quite a lot about Linux by having to struggle, with your help, to find solutions to the problems I encountered (I am still very new to Linux), but maybe we need to log these problems somewhere to make it less of a struggle for others like me. I have used the PortLister example to test it and it came up with my USB to dual Serial adaptor Ports. I will now explore the RxTx package, before I tackle the windows installation, I will let you know of my experience. Thank you for all your Help. Best Regards Luis From tjarvi at qbang.org Sun May 3 10:37:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 3 May 2009 10:37:50 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FD4823.5080204@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> <49FD4823.5080204@ntlworld.com> Message-ID: On Sun, 3 May 2009, Luis Moreira wrote: > Ah >> >> when you do cvs update pass the -Pd option >> >> cvs update -Pd >> >> Also, when you run configure, use --disable-PRINTER to only build the >> serial support. It will make things easier. --disable-LOCKFILES will >> also be easier to get going until you want to learn about how to >> prevent multiple applications from reading the same serial port. >> >> The link for debugging will describe where the files go. By default, >> it will install in the JRE/JDK under >> >> jre/lib/ext (the jar file) >> jre/lib/i386 (the .so file) >> >> Those are on the proper paths when you use the sun or ibm jdk. >> >> http://rxtx.qbang.org/wiki/index.php/Trouble_shooting >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > It as done it! > I think this instructions you gave me should be on the Wiki, I can write > them for you if you like. Also on the Wiki when you describe the three > methods of installing the RxTx package it is confusing because as far > as I can see, you always have to do method 1 or the .so files will not > be generated(is this correct?). Then you can if you like change the > location with method 1 & 2. Is it possible to modify the .la file to > point to different directories for installation and then you can decide > where to place the files? > In a way I have learned quite a lot about Linux by having to struggle, > with your help, to find solutions to the problems I encountered (I am > still very new to Linux), but maybe we need to log these problems > somewhere to make it less of a struggle for others like me. > > I have used the PortLister example to test it and it came up with my USB > to dual Serial adaptor Ports. > > I will now explore the RxTx package, before I tackle the windows > installation, I will let you know of my experience. > > Thank you for all your Help. > Hi Luis, The locations suggested for first time configuration could be documented in a new wiki page explaining that this is not the recommended general workflow but does help new users that are not worried about having rxtx installed into the JRE. For a professional environment, the user would want to follow the workflow currently on the wiki and keep their JRE clean. Often the user will not be able to add libraries to the JRE and will need to use their home directory or a sandbox. Feel free to add information to the wiki. I'd suggest creating comment in the current page and have the comment link to what worked for you as a first time user new to Linux. You can create a new page with your comments. In the long term, we will be working on an autoinstaller that works over the web. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Mon May 4 09:15:40 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Mon, 04 May 2009 16:15:40 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FF069C.8040406@ntlworld.com> Hi Trent, I have now installed the package on my 64 bit machine and when I run my program I get errors on the attachment. I know it as something to do with the architecture of my system but I can no figure out how to fix it. I have built it from source again, I did not transfer the files from machine to machine. can you please put me in the right direction. Thank you very much for your help. Best Regards Luis -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshoot.png Type: image/png Size: 25753 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090504/141ab5dc/attachment-0013.png From johnny.luong at trustcommerce.com Mon May 4 11:57:08 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 04 May 2009 10:57:08 -0700 Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FF069C.8040406@ntlworld.com> References: <49FF069C.8040406@ntlworld.com> Message-ID: <49FF2C74.90805@trustcommerce.com> Luis Moreira wrote: > Hi Trent, > I have now installed the package on my 64 bit machine and when I run my > program I get errors on the attachment. I know it as something to do > with the architecture of my system but I can no figure out how to fix > it. I have built it from source again, I did not transfer the files from > machine to machine. > can you please put me in the right direction. > Thank you very much for your help. > Best Regards > Luis > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Hi, Does running it on a 64-bit JVM help? Your host environment might be building objects for a 64-bit environment unless you did a cross-compile... -- you can find out by doing something like the following: johnny at spike:~$ java -version java version "1.6.0_0" OpenJDK Runtime Environment (build 1.6.0_0-b11) OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode) johnny at spike:~$ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) -Johnny From huangdongkai at gmail.com Wed May 6 11:06:06 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 01:06:06 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. Message-ID: Dear all, I recompile the rxtxSerial source code by MinGW32 and compile success. But when I run my Application which use rxtxSerial.dll to communicate with serial port, a runtime exception happened and application crash. I have no idea why it can not work, beacuse i have not change any source code of rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I have missed when compile the source code on Window NT? Here below is the output error massage. # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, tid=1360 # # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing windows-x86) # Problematic frame: # V [jvm.dll+0x1b6824] # # An error report file with more information is saved as: # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/32c1e699/attachment-0011.html From tjarvi at qbang.org Wed May 6 20:04:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 May 2009 20:04:10 -0600 (MDT) Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: On Thu, 7 May 2009, dongkai huang wrote: > Dear all, > ????? I recompile the rxtxSerial source code by MinGW32 and compile success. > But when I run my Application which use rxtxSerial.dll to communicate with > serial port, a runtime exception happened and application crash.? I have no > idea why it can not work, beacuse i have not change any source code of > rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I > have missed when compile the source code on Window NT? Here below is the > output error massage. > # > # An unexpected error has been detected by Java Runtime Environment: > # > #? EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, > tid=1360 > # > # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing > windows-x86) > > # Problematic frame: > # V? [jvm.dll+0x1b6824] > # > # An error report file with more information is saved as: > # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log > # > # If you would like to submit a bug report, please visit: > #?? http://java.sun.com/webapps/bugreport/crash.jsp > # > > > Hi Dongkai Could you explain how you compiled rxtx with mingw? Did you run configure? Was the compiler native or a cross compiler (like compiling on Linux for Windows)? Is the crash happening when you first open the port or is it happening randomly later on? -- Trent Jarvi tjarvi at qbang.org From huangdongkai at gmail.com Wed May 6 20:48:56 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 10:48:56 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Hi Trent, I was followed the step on INSTALL file, did not run the configure, I used the Makefile.mingw32 which include on the source code package, and only change some path( jdk home path etc.). And I use the native compiler on Windows. The crash happened on I call the getPortIdentifiers() every time. On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Dear all, >> I recompile the rxtxSerial source code by MinGW32 and compile >> success. >> But when I run my Application which use rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and application crash. I have >> no >> idea why it can not work, beacuse i have not change any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing >> I >> have missed when compile the source code on Window NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is saved as: >> # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> > Hi Dongkai > > Could you explain how you compiled rxtx with mingw? Did you run configure? > Was the compiler native or a cross compiler (like compiling on Linux for > Windows)? > > Is the crash happening when you first open the port or is it happening > randomly later on? > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/733eded5/attachment-0011.html From m.j.tandy at warwick.ac.uk Thu May 7 10:39:12 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 7 May 2009 17:39:12 +0100 Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. Message-ID: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> I've encountered a bug in how XON/XOFF are handled on Windows. The symptoms were: 1. XON/XOFF from device to PC did not stop transmission. 2. XON/XOFF characters were present in data read from serial port input stream, when it was expected that they would be stripped out. 3. Investigation with SysInternals PortMon revealed the following configuration when using rxtx: 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 while HyperTerminal, which did not have the same problems as me, produced the following: 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 In other words, the problem is that, in addition to being told to use XON/XOFF flow control, the computer has to explicitly be told which characters to use for 'XON' and 'XOFF'. This part of the configuration was being missed out. I got the latest rxtx source from CVS, and identified the problem as an omission in the 'init_termios' function of 'termios.c', which configures the unix/termios 'c_cc' (control characters) data structure - but omits to configure the VSTART and VSTOP control characters. Later, the termios c_cc data structure is translated (by termios_to_DCB) into a data structure named 'DCB', which is passed to the windows serial port configuration interface. By adding two lines defining the standard XON/XOFF characters to the function init_termios, the bug is fixed. A patch doing this is attached. Thanks, Michael Tandy -------------- next part -------------- A non-text attachment was scrubbed... Name: xon-xoff.diff Type: application/octet-stream Size: 667 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/159c0dcc/attachment-0010.obj From tjarvi at qbang.org Thu May 7 17:57:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 May 2009 17:57:28 -0600 (MDT) Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. In-Reply-To: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> References: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> Message-ID: On Thu, 7 May 2009, Michael Tandy wrote: > I've encountered a bug in how XON/XOFF are handled on Windows. > > The symptoms were: > 1. XON/XOFF from device to PC did not stop transmission. > 2. XON/XOFF characters were present in data read from serial port > input stream, when it was expected that they would be stripped out. > 3. Investigation with SysInternals PortMon revealed the following > configuration when using rxtx: > > 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 > BRK:0 EVT:a XON:0 XOFF:0 > > while HyperTerminal, which did not have the same problems as me, > produced the following: > > 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 > > In other words, the problem is that, in addition to being told to use > XON/XOFF flow control, the computer has to explicitly be told which > characters to use for 'XON' and 'XOFF'. This part of the configuration > was being missed out. > > I got the latest rxtx source from CVS, and identified the problem as > an omission in the 'init_termios' function of 'termios.c', which > configures the unix/termios 'c_cc' (control characters) data structure > - but omits to configure the VSTART and VSTOP control characters. > Later, the termios c_cc data structure is translated (by > termios_to_DCB) into a data structure named 'DCB', which is passed to > the windows serial port configuration interface. > > By adding two lines defining the standard XON/XOFF characters to the > function init_termios, the bug is fixed. A patch doing this is > attached. > Thanks Michael, Good timing. I plan on releasing rxtx-2.2 this coming Sunday. -- Trent Jarvi tjarvi at qbang.org From wjr at weru.ksu.edu Fri May 8 11:38:29 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Fri, 08 May 2009 12:38:29 -0500 Subject: [Rxtx] swing jfilechooser lockup Message-ID: <4A046E15.6010907@weru.ksu.edu> Hi, I wrote a small swing app to download images from an industrial camera. I used the two way serial sample code as a starting point. The app works fine EXCEPT for a call to jfilechooser. After I open the comm port and then try to change the output directory or log file, the jfilechooser winds up trying to unpark (note, parking is not something I'm really familiar with) and doesn't. If I try to change the file or directory before I start the comm port, it works. If I click on menu items that don't call jfilechooser, everything is OK. If I try closing the comm port and then try to create a jfilechooser, it locks up. There is obviously some sort of deadlock here because the awt thread starts waiting on something but it's not clear what. I haven't gone thru the rxtx code yet because it's not in the file structure that netbeans wants for debugging purposes. However, debugging code that I don't have a clear idea of what it is supposed to do is not my idea of a good time. Does anyone have any ideas on what is going on here? Thanks, wjr From Bob_Jacobsen at lbl.gov Fri May 8 14:48:25 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Fri, 8 May 2009 13:48:25 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A046E15.6010907@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> Message-ID: At 12:38 PM -0500 5/8/09, Bill Rust wrote: >Hi, > >I wrote a small swing app to download images from an industrial camera. >I used the two way serial sample code as a starting point. The app works >fine EXCEPT for a call to jfilechooser. After I open the comm port and >then try to change the output directory or log file, the jfilechooser >winds up trying to unpark (note, parking is not something I'm really >familiar with) and doesn't. If I try to change the file or directory >before I start the comm port, it works. If I click on menu items that >don't call jfilechooser, everything is OK. If I try closing the comm >port and then try to create a jfilechooser, it locks up. There is >obviously some sort of deadlock here because the awt thread starts >waiting on something but it's not clear what. I haven't gone thru the >rxtx code yet because it's not in the file structure that netbeans wants >for debugging purposes. However, debugging code that I don't have a >clear idea of what it is supposed to do is not my idea of a good time. What is the threading structure of your code? The various high-function Swing components, such as JFileChooser, are notorious for doing Really Bad Stuff when invoked from off the Swing thread. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From bschlining at gmail.com Fri May 8 15:08:50 2009 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 8 May 2009 14:08:50 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: Bob's probably right...take look at javax.swing.SwingUtilites for the workaround to get your swing stuff invoked on the EventDispatchThread (EDT). Some swing-methods do work when called outside of the EDT, but just to be safe, do your creation and swing calls on the EDT. It's really simple, here's an example of a synchronous call. // Here's how to run stuff on the EDT from a different thread SwingUtilities.invokeAndWait(new Runnable() { public void run() { JFileChooser fc; // create, setup, show your filechooser // Get the result from the filechooser } }); To do a asynchronous call use SwingUtilities.invokeLater > >I wrote a small swing app to download images from an industrial camera. > >I used the two way serial sample code as a starting point. The app works > >fine EXCEPT for a call to jfilechooser. After I open the comm port and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090508/c21c2127/attachment-0009.html From tod at todbot.com Fri May 8 16:27:12 2009 From: tod at todbot.com (Tod E. Kurt) Date: Fri, 8 May 2009 15:27:12 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> This is the exact technique I use to let the user choose which serial port to use on startup. Here's a method I've got in many of my sketches: void choosePort() { String portlist[] = Serial.list(); String port = null; javax.swing.SwingUtilities.invokeLater(new Runnable() { public void run() { try { String port = (String) javax.swing.JOptionPane.showInputDialog( null, "Select Serial Port", "MySuperSketch", javax.swing.JOptionPane.QUESTION_MESSAGE, null, portlist, null); if( port == null ) { javax.swing.JOptionPane.showMessageDialog(null, "No port chosen, goodbye"); System.exit(1); } serialPort = port; } catch (Exception e) { e.printStackTrace(); } } } ); } On May 8, 2009, at 2:08 p, Brian Schlining wrote: > Bob's probably right...take look at javax.swing.SwingUtilites for > the workaround to get your swing stuff invoked on the > EventDispatchThread (EDT). Some swing-methods do work when called > outside of the EDT, but just to be safe, do your creation and swing > calls on the EDT. It's really simple, here's an example of a > synchronous call. > > // Here's how to run stuff on the EDT from a different thread > SwingUtilities.invokeAndWait(new Runnable() { > public void run() { > JFileChooser fc; // create, setup, show your filechooser > // Get the result from the filechooser > } > }); > > To do a asynchronous call use SwingUtilities.invokeLater > > > >I wrote a small swing app to download images from an industrial > camera. > >I used the two way serial sample code as a starting point. The app > works > >fine EXCEPT for a call to jfilechooser. After I open the comm port > and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From huangdongkai at gmail.com Sat May 9 04:46:22 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Sat, 9 May 2009 18:46:22 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Dear Trent, After I intsall the ming32-cross compile to compile the rxtxSerial.dll and testing, i found the same problem still exist. I am not sure my compiler version is the same as your's. Could you tell me the way you can success compile rxtx-2.1-7r2 release source code? Thanks for you kindly help. On Fri, May 8, 2009 at 8:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Hi Trent, >> The attach is the Make file I use to compile the rxtx. >> >> On Thu, May 7, 2009 at 10:48 AM, dongkai huang >> wrote: >> Hi Trent, >> I was followed the step on INSTALL file, did not run the >> configure, I used the Makefile.mingw32 which include on the >> source code package, and only change some path( jdk home path >> etc.). And I use the native compiler on Windows. >> The crash happened on I call the getPortIdentifiers() >> every time. >> >> On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: >> >> >> On Thu, 7 May 2009, dongkai huang wrote: >> >> Dear all, >> I recompile the rxtxSerial source code by >> MinGW32 and compile success. >> But when I run my Application which use >> rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and >> application crash. I have no >> idea why it can not work, beacuse i have not change >> any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source >> code. Did some thing I >> have missed when compile the source code on Window >> NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java >> Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at >> pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 >> mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is >> saved as: >> # >> D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please >> visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> >> Hi Dongkai >> >> Could you explain how you compiled rxtx with mingw? Did you run >> configure? Was the compiler native or a cross compiler (like >> compiling on Linux for Windows)? >> >> Is the crash happening when you first open the port or is it >> happening randomly later on? >> >> > Thanks Dongkai > > I'll look at your Makefile tomorrow. Which version of mingw was this? > > I suspect there is a problem with that makefile. I usually built that > version of rxtx for windows with a mingw32 cross compiler using the > configure script. > > The configure script may well work for you if you have a cygwin environment > with mingw instead of gcc. I'll take a look at what is different. > > -- > > Trent Jarvi > tjarvi at qbang.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090509/b729c429/attachment-0009.html From wjr at weru.ksu.edu Wed May 13 15:50:30 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Wed, 13 May 2009 16:50:30 -0500 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> Message-ID: <4A0B40A6.5070204@weru.ksu.edu> Tod's solution misses the point. He is picking and opening the serial port. That's the step before where my problem occurs. To recap: 1. I have a simple java swing app. 2. On the menu bar, there is the standard set, file, etc., of jmenu's. Under file, there is a jmenuitem, logfileopen, which pops up a jfilechooser to select a logfile and another jmenuitem, setprefix, which pops up a jdialog to allow the user to type in a file name prefix for downloaded images. 3. There is another jmenuitem that starts the commport running. 4. When logfileopen is pressed before the commport is started, it works. 5. When logfileopen is pressed after the commport is started, it hangs. 6. setprefix works whether or not the commport is started. 7. portIdentifier.open starts a thread that goes into a native method, RXTXPort.eventLoop, and never returns. 8. java.sun bugs has a bug report, 6741890, that is similar but their workaround doesn't. 9. When it locks up, there is a swing-shell thread that appears to be down in some native libraries, winshellfolder2 10. The awt-eventQ thread is unblocked but in code that says its parked. If you have anymore ideas, I'd really appreciate them. wjr Tod E. Kurt wrote: > This is the exact technique I use to let the user choose which serial > port to use on startup. Here's a method I've got in many of my sketches: > > void choosePort() { > String portlist[] = Serial.list(); > String port = null; > javax.swing.SwingUtilities.invokeLater(new Runnable() { > public void run() { > try { > String port = (String) javax.swing.JOptionPane.showInputDialog( > null, > "Select Serial Port", > "MySuperSketch", > javax.swing.JOptionPane.QUESTION_MESSAGE, > null, portlist, null); > if( port == null ) { > javax.swing.JOptionPane.showMessageDialog(null, "No port > chosen, goodbye"); > System.exit(1); > } > serialPort = port; > } > catch (Exception e) { > e.printStackTrace(); > } > } > } ); > } > > > On May 8, 2009, at 2:08 p, Brian Schlining wrote: > >> Bob's probably right...take look at javax.swing.SwingUtilites for the >> workaround to get your swing stuff invoked on the EventDispatchThread >> (EDT). Some swing-methods do work when called outside of the EDT, but >> just to be safe, do your creation and swing calls on the EDT. It's >> really simple, here's an example of a synchronous call. >> >> // Here's how to run stuff on the EDT from a different thread >> SwingUtilities.invokeAndWait(new Runnable() { >> public void run() { >> JFileChooser fc; // create, setup, show your filechooser >> // Get the result from the filechooser >> } >> }); >> >> To do a asynchronous call use SwingUtilities.invokeLater >> >> >> >I wrote a small swing app to download images from an industrial camera. >> >I used the two way serial sample code as a starting point. The app works >> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >> >then try to change the output directory or log file, the jfilechooser >> >winds up trying to unpark (note, parking is not something I'm really >> >familiar with) and doesn't. >> What is the threading structure of your code? >> >> The various high-function Swing components, such as JFileChooser, are >> notorious for doing Really Bad Stuff when invoked from off the Swing >> thread. >> >> Bob >> -- >> Bob Jacobsen, UC Berkeley >> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >> JacobsenRG >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -- >> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >> Brian Schlining >> bschlining at gmail.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx From m.j.tandy at warwick.ac.uk Wed May 13 16:42:24 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 13 May 2009 23:42:24 +0100 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A0B40A6.5070204@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> <4A0B40A6.5070204@weru.ksu.edu> Message-ID: <302aa0340905131542i601ec3f1w3b0b5879c23f8eca@mail.gmail.com> Perhaps you could post your program, or an excerpt of it sufficient to demonstrate the problem you're having, for us to have a look at? 2009/5/13 Bill Rust : > Tod's solution misses the point. He is picking and opening the serial > port. That's the step before where my problem occurs. > > To recap: > > 1. I have a simple java swing app. > 2. On the menu bar, there is the standard set, file, etc., of jmenu's. > Under file, there is a jmenuitem, logfileopen, which pops up a > jfilechooser to select a logfile and another jmenuitem, setprefix, which > pops up a jdialog to allow the user to type in a file name prefix for > downloaded images. > 3. There is another jmenuitem that starts the commport running. > 4. When logfileopen is pressed before the commport is started, it works. > 5. When logfileopen is pressed after the commport is started, it hangs. > 6. setprefix works whether or not the commport is started. > 7. portIdentifier.open starts a thread that goes into a native > method, ? ? ? ? ? ? ? ? ? ? ? ? RXTXPort.eventLoop, and never returns. > 8. java.sun bugs has a bug report, 6741890, that is similar but > their ? ? ? ? ? ? ? ? ? workaround doesn't. > 9. When it locks up, there is a swing-shell thread that appears to be > ? ? ? ?down in some native libraries, winshellfolder2 > 10. The awt-eventQ thread is unblocked but in code that says its parked. > > If you have anymore ideas, I'd really appreciate them. > > wjr > > Tod E. Kurt wrote: >> This is the exact technique I use to let the user choose which serial >> port to use on startup. ?Here's a method I've got in many of my sketches: >> >> void choosePort() { >> ? String portlist[] = Serial.list(); >> ? String port = null; >> ? javax.swing.SwingUtilities.invokeLater(new Runnable() { >> ? ? public void run() { >> ? ? ? try { >> ? ? ? ? String port = (String) javax.swing.JOptionPane.showInputDialog( >> null, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Select Serial Port", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "MySuperSketch", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? javax.swing.JOptionPane.QUESTION_MESSAGE, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? null, portlist, null); >> ? ? ? ? if( port == null ) ?{ >> ? ? ? ? ? javax.swing.JOptionPane.showMessageDialog(null, "No port >> chosen, goodbye"); >> ? ? ? ? ? System.exit(1); >> ? ? ? ? } >> ? ? ? ? serialPort = port; >> ? ? ? } >> ? ? ? catch (Exception e) { >> ? ? ? ? e.printStackTrace(); >> ? ? ? } >> ? ? } >> ? } ); >> } >> >> >> On May 8, 2009, at 2:08 p, Brian Schlining wrote: >> >>> Bob's probably right...take look at javax.swing.SwingUtilites for the >>> workaround to get your swing stuff invoked on the EventDispatchThread >>> (EDT). Some swing-methods do work when called outside of the EDT, but >>> just to be safe, do your creation and swing calls on the EDT. It's >>> really simple, here's an example of a synchronous call. >>> >>> // Here's how to run stuff on the EDT from a different thread >>> SwingUtilities.invokeAndWait(new Runnable() { >>> ? ? ? public void run() { >>> ? ? ? ? ? ?JFileChooser fc; // create, setup, show your filechooser >>> ? ? ? ? ? ?// Get the result from the filechooser >>> ? ? ? } >>> }); >>> >>> To do a asynchronous call use SwingUtilities.invokeLater >>> >>> >>> >I wrote a small swing app to download images from an industrial camera. >>> >I used the two way serial sample code as a starting point. The app works >>> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >>> >then try to change the output directory or log file, the jfilechooser >>> >winds up trying to unpark (note, parking is not something I'm really >>> >familiar with) and doesn't. >>> What is the threading structure of your code? >>> >>> The various high-function Swing components, such as JFileChooser, are >>> notorious for doing Really Bad Stuff when invoked from off the Swing >>> thread. >>> >>> Bob >>> -- >>> Bob Jacobsen, UC Berkeley >>> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >>> JacobsenRG >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >>> -- >>> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >>> Brian Schlining >>> bschlining at gmail.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From m.j.tandy at warwick.ac.uk Thu May 14 03:05:36 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 14 May 2009 10:05:36 +0100 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A0B40A6.5070204@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> <4A0B40A6.5070204@weru.ksu.edu> Message-ID: <302aa0340905140205p6ceb5a9br24e00a50e9cafa5@mail.gmail.com> Java has a built in deadlock detection utility; run your program from the command line, then (on windows) press Ctrl+Break (On Linux, Ctrl+\ does the trick I'm told). That should produce status information and a stack trace for every running thread, including locks held and locks waited on. Maybe that would contain enough information for you to work out what's locking what? 2009/5/13 Bill Rust : > Tod's solution misses the point. He is picking and opening the serial > port. That's the step before where my problem occurs. > > To recap: > > 1. I have a simple java swing app. > 2. On the menu bar, there is the standard set, file, etc., of jmenu's. > Under file, there is a jmenuitem, logfileopen, which pops up a > jfilechooser to select a logfile and another jmenuitem, setprefix, which > pops up a jdialog to allow the user to type in a file name prefix for > downloaded images. > 3. There is another jmenuitem that starts the commport running. > 4. When logfileopen is pressed before the commport is started, it works. > 5. When logfileopen is pressed after the commport is started, it hangs. > 6. setprefix works whether or not the commport is started. > 7. portIdentifier.open starts a thread that goes into a native > method, ? ? ? ? ? ? ? ? ? ? ? ? RXTXPort.eventLoop, and never returns. > 8. java.sun bugs has a bug report, 6741890, that is similar but > their ? ? ? ? ? ? ? ? ? workaround doesn't. > 9. When it locks up, there is a swing-shell thread that appears to be > ? ? ? ?down in some native libraries, winshellfolder2 > 10. The awt-eventQ thread is unblocked but in code that says its parked. > > If you have anymore ideas, I'd really appreciate them. > > wjr > > Tod E. Kurt wrote: >> This is the exact technique I use to let the user choose which serial >> port to use on startup. ?Here's a method I've got in many of my sketches: >> >> void choosePort() { >> ? String portlist[] = Serial.list(); >> ? String port = null; >> ? javax.swing.SwingUtilities.invokeLater(new Runnable() { >> ? ? public void run() { >> ? ? ? try { >> ? ? ? ? String port = (String) javax.swing.JOptionPane.showInputDialog( >> null, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Select Serial Port", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "MySuperSketch", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? javax.swing.JOptionPane.QUESTION_MESSAGE, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? null, portlist, null); >> ? ? ? ? if( port == null ) ?{ >> ? ? ? ? ? javax.swing.JOptionPane.showMessageDialog(null, "No port >> chosen, goodbye"); >> ? ? ? ? ? System.exit(1); >> ? ? ? ? } >> ? ? ? ? serialPort = port; >> ? ? ? } >> ? ? ? catch (Exception e) { >> ? ? ? ? e.printStackTrace(); >> ? ? ? } >> ? ? } >> ? } ); >> } >> >> >> On May 8, 2009, at 2:08 p, Brian Schlining wrote: >> >>> Bob's probably right...take look at javax.swing.SwingUtilites for the >>> workaround to get your swing stuff invoked on the EventDispatchThread >>> (EDT). Some swing-methods do work when called outside of the EDT, but >>> just to be safe, do your creation and swing calls on the EDT. It's >>> really simple, here's an example of a synchronous call. >>> >>> // Here's how to run stuff on the EDT from a different thread >>> SwingUtilities.invokeAndWait(new Runnable() { >>> ? ? ? public void run() { >>> ? ? ? ? ? ?JFileChooser fc; // create, setup, show your filechooser >>> ? ? ? ? ? ?// Get the result from the filechooser >>> ? ? ? } >>> }); >>> >>> To do a asynchronous call use SwingUtilities.invokeLater >>> >>> >>> >I wrote a small swing app to download images from an industrial camera. >>> >I used the two way serial sample code as a starting point. The app works >>> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >>> >then try to change the output directory or log file, the jfilechooser >>> >winds up trying to unpark (note, parking is not something I'm really >>> >familiar with) and doesn't. >>> What is the threading structure of your code? >>> >>> The various high-function Swing components, such as JFileChooser, are >>> notorious for doing Really Bad Stuff when invoked from off the Swing >>> thread. >>> >>> Bob >>> -- >>> Bob Jacobsen, UC Berkeley >>> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >>> JacobsenRG >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >>> -- >>> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >>> Brian Schlining >>> bschlining at gmail.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From cowwoc at bbs.darktech.org Fri May 15 07:18:29 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 09:18:29 -0400 Subject: [Rxtx] InputStream timeouts Message-ID: <4A0D6BA5.8020209@bbs.darktech.org> Why does InputStream.read() return -1 on timeout instead of throwing InterruptedIOException which has existed specifically for this purpose since JDK 1.0? Sockets throw SocketTimeoutException which extends InterruptedIOException. I suspect that this logic confuses BufferedInputStream as well as end-users. Can we introduce this change along with the other timeout-related changes? Gili From Steffen.DETTMER at ingenico.com Fri May 15 07:36:19 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 15 May 2009 15:36:19 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0D6BA5.8020209@bbs.darktech.org> References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <20090515133619.GC17036@elberon.bln.de.ingenico.com> * cowwoc wrote on Fri, May 15, 2009 at 09:18 -0400: > Why does InputStream.read() return -1 on timeout shouldn't it block and only avialable() should care about timeouts? That is how I understand `This method blocks until input data is available' from: http://java.sun.com/j2se/1.5.0/docs/api/java/io/InputStream.html#read() public abstract int read() throws IOException Reads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. A subclass must provide an implementation of this method. Returns: the next byte of data, or -1 if the end of the stream is reached. Throws: IOException - if an I/O error occurs. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Fri May 15 08:22:19 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 15 May 2009 17:22:19 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: >From the javadoc for InputStream: "If no byte is available because the end of the stream has been reached, the value -1 is returned." Since character timeout is not an indication of EOF condition I guess one could argue that 0 should be returned in case of timeout. On the other hand one could also argue that since no data was available (if it timed out) the serial port input stream was at the end of stream (albeit possibly temporarily only). Further the javadoc seems to forbid the return value 0 for Inputstream.read(): " This method blocks until input data is available, the end of the stream is detected, or an exception is thrown." So it can return n >= 1 , -1 or throw an exception. InputStream.read(byte[]) can return 0 but for consistency the options with the other read methods the return value for timeout needs to be -1 or an exception. It goes against my grain to think that I get an exception when I've set up a timeout and I am thus expecting a timeout to happen sometimes. So it is not an exceptional case but expected situation in which case a special return value is philosophically speaking more appropriate. So I'm against changing this behavior. I expect a lot of code depend on the -1 or at least on not getting an exception when a timeout occurs. In any case if an exception were to be thrown it should *not* be InterruptedIOException. >From the javadoc for InterruptedIOException: "An InterruptedIOException is thrown to indicate that an input or output transfer has been terminated because the thread performing it was interrupted. The field bytesTransferred indicates how many bytes were successfully transferred before the interruption occurred" I do not think this matches the case for serial port receive character timeout. I read the javadoc above so that I get this exception when the thread in my code that is performing a read or write operation gets interrupted by Thread.interrupt(). And this is used to handle exactly that case: being able to gracefully and cleanly interrupt threads. my 2 snt worth br Kusti > From: cowwoc > Date: Fri, 15 May 2009 16:18:29 +0300 > To: rxtx > Conversation: [Rxtx] InputStream timeouts > Subject: [Rxtx] InputStream timeouts > > > > Why does InputStream.read() return -1 on timeout instead of > throwing InterruptedIOException which has existed specifically for this > purpose since JDK 1.0? Sockets throw SocketTimeoutException which > extends InterruptedIOException. I suspect that this logic confuses > BufferedInputStream as well as end-users. Can we introduce this change > along with the other timeout-related changes? > > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From cowwoc at bbs.darktech.org Fri May 15 08:35:27 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 10:35:27 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <4A0D7DAF.5030705@bbs.darktech.org> I disagree with your interpretation. Read SocketTimeoutException to see what I mean. InterruptedIOException means the operation was interrupted, not necessarily by way of Thread.interrupt(). Returning 0 in case of timeout sounds wrong to me because it is a legal byte value that could have been read. Returning -1 also sounds wrong to me because this isn't strictly the end of stream. BufferedInputStream and others assume that once you reach the end of stream you will never see more data, ever. As far as I know, the core APIs are written in terms of throwing InterruptedIOException for timeouts. Gili Kustaa Nyholm wrote: > >>From the javadoc for InputStream: > > "If no byte is available because the end of the stream has been reached, the > value -1 is returned." > > > Since character timeout is not an indication of EOF condition I guess one > could argue that 0 should be returned in case of timeout. On the other hand > one could also argue that since no data was available (if it timed out) the > serial port input stream was at the end of stream (albeit possibly > temporarily only). Further the javadoc seems to forbid the return value 0 > for Inputstream.read(): > > " This method blocks until input data is available, the end of the stream is > detected, or an exception is thrown." > > So it can return n >= 1 , -1 or throw an exception. InputStream.read(byte[]) > can return 0 but for consistency the options with the other read methods the > return value for timeout needs to be -1 or an exception. > > It goes against my grain to think that I get an exception when I've set up a > timeout and I am thus expecting a timeout to happen sometimes. So it is not > an exceptional case but expected situation in which case a special return > value is philosophically speaking more appropriate. > > So I'm against changing this behavior. I expect a lot of code depend on the > -1 or at least on not getting an exception when a timeout occurs. > > In any case if an exception were to be thrown it should *not* be > InterruptedIOException. > >>From the javadoc for InterruptedIOException: > > > "An InterruptedIOException is thrown to indicate that an input or output > transfer has been terminated because the thread performing it was > interrupted. The field bytesTransferred indicates how many bytes were > successfully transferred before the interruption occurred" > > I do not think this matches the case for serial port receive character > timeout. I read the javadoc above so that I get this exception when the > thread in my code that is performing a read or write operation gets > interrupted by Thread.interrupt(). And this is used to handle exactly that > case: being able to gracefully and cleanly interrupt threads. > > > > my 2 snt worth br Kusti > > > > >> From: cowwoc >> Date: Fri, 15 May 2009 16:18:29 +0300 >> To: rxtx >> Conversation: [Rxtx] InputStream timeouts >> Subject: [Rxtx] InputStream timeouts >> >> >> >> Why does InputStream.read() return -1 on timeout instead of >> throwing InterruptedIOException which has existed specifically for this >> purpose since JDK 1.0? Sockets throw SocketTimeoutException which >> extends InterruptedIOException. I suspect that this logic confuses >> BufferedInputStream as well as end-users. Can we introduce this change >> along with the other timeout-related changes? >> >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From m.j.tandy at warwick.ac.uk Fri May 15 09:17:36 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Fri, 15 May 2009 16:17:36 +0100 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <302aa0340905150817o39812d7y1b896004a2dcc2ab@mail.gmail.com> > I disagree with your interpretation. Read SocketTimeoutException to see > what I mean. InterruptedIOException means the operation was interrupted, > not necessarily by way of Thread.interrupt(). Strangely enough, the javadoc for InterruptedIOException says: "An InterruptedIOException is thrown to indicate that an input or output transfer has been terminated because the thread performing it was interrupted."[1] But the subclass SocketTimeoutException is used differently - here's an example from sun.net.httpserver.request: /** * block() only called when available==0 and buf is empty */ private synchronized void block () throws IOException { long currtime = server.getTime(); long maxtime = currtime + readTimeout; while (currtime < maxtime) { if (selector.select (readTimeout) == 1) { selector.selectedKeys().clear(); available (); return; } currtime = server.getTime(); } throw new SocketTimeoutException ("no data received"); } So it seems that SocketTimeoutExceptions get thrown not upon thread interruptions, but a certain time after a blocking read is started. [1] http://java.sun.com/javase/6/docs/api/java/io/InterruptedIOException.html From cowwoc at bbs.darktech.org Fri May 15 11:06:53 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 13:06:53 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0DA0F4.9050203@bbs.darktech.org> References: <4A0DA0F4.9050203@bbs.darktech.org> Message-ID: <4A0DA12D.2050303@bbs.darktech.org> Forgot to CC the list. Gili cowwoc wrote: > > "Thread was interrupted" does not necessarily mean > Thread.interrupt(). It just means that the operation (run by the thread) > was interrupted. If you read the beginning sentence for > InterruptedIOException it reads "Signals that an I/O operation has been > interrupted". This says nothing about the thread itself. Michael's > subsequent post about SocketTimeoutException reinforces that point. > > By the way, I think that in general you need to interpret the > Javadoc for core classes in a broader sense than it seems. Older Javadoc > (from version 1.0) used to mention implementation details that were not > necessarily important and limited the applicability of the classes. > Newer documentation tends to go out of its way to avoid mentioning such > implementation detail and I believe that's a good thing. When > InterruptedIOException was written, Thread.interrupt() was probably the > only way to interrupt I/O operations. Nowadays there are others. Sun has > generalized its meaning over time as evident by SocketTimeoutException. > At least, that's my interpretation :) > > Gili > > Kustaa Nyholm wrote: >>> I disagree with your interpretation. Read >>> SocketTimeoutException to >>> see >>> what I mean. InterruptedIOException means the operation was interrupted, >>> not necessarily by way of Thread.interrupt(). >> >> Well SocketTimeoutException javadoc only says, very briefly: >> >> "Signals that a timeout has occurred on a socket read or accept." >> >> So that is not too helpful. But since it is derived from >> InterruptedIOException my interpretation it that they have an 'is-a' >> relationship and InterruptedIOException needs to honor the contract of >> InterruptedIOException which says: >> >> "...because the thread performing it was interrupted." >> >> To me this very specifically talks about interrupting threads with >> Thread.interrupt() >> >> >>> Returning 0 in case of timeout sounds wrong to me because it >>> is a >>> legal >>> byte value that could have been read. >> Agreed, that's what I tried to say. 0 is a legal byte value for read() to >> return so that cannot be used. For read read(byte[]) which returns the >> number of bytes read 0 could be used but there again 0 can be returned >> if 0 >> byte[] size is 0. So there again 0 is not a good option. >> >>> Returning -1 also sounds wrong to >>> me because this isn't strictly the end of stream. >> Like I said, it isn't strictly the end of stream. But also does not >> forbid treating it as (temporary) end of stream. >> >>> BufferedInputStream >>> and others assume that once you reach the end of stream you will never >>> see more data, ever. >> Can you provide a reference for that. >> >>> As far as I know, the core APIs are written in >>> terms of throwing InterruptedIOException for timeouts. >> Would also like to see something to support that. >> >> >> The behavior of throwing an exception on timeout is also a little bit >> problematic, consider: >> >> byte buf[1000]; >> int n=ins.read(buf); >> // do something with the n bytes received >> >> What happens if a timeout occurs before we have received 1000 bytes? >> >> If an exception is thrown then the user of the read() needs to handle >> the bytes received in two places or else those last <1000 bytes are lost. >> A better solution would be to return the bytes received so far and throw >> the exception on the next call (if any). But the main point is that >> neither of these case obviously correct and neither is specified in the >> javadocs. Where as a lot of code that just handles the return value >> of read(byte[]) correctly works without any further ado. >> >> >> >> The main thing is that I think we should not break existing applications, >> which I expect are not handling InterruptedIOException but many of >> which may >> depend on getting back -1 in case of timeouts. >> >> It has been a while since I used the javax.javacomm but I seem to recall >> that it returned -1 and I think this is the defining standard. >> >> I expect most rxtx users are more interested in compatibility and >> stability >> than semantic niceties and improving the API. >> >> br Kusti >> >> >> > From johnny.luong at trustcommerce.com Fri May 15 13:16:15 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Fri, 15 May 2009 12:16:15 -0700 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0DA12D.2050303@bbs.darktech.org> References: <4A0DA0F4.9050203@bbs.darktech.org> <4A0DA12D.2050303@bbs.darktech.org> Message-ID: <4A0DBF7F.50808@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 cowwoc wrote: | Forgot to CC the list. | | Gili | | cowwoc wrote: |> "Thread was interrupted" does not necessarily mean |> Thread.interrupt(). It just means that the operation (run by the thread) |> was interrupted. If you read the beginning sentence for |> InterruptedIOException it reads "Signals that an I/O operation has been |> interrupted". This says nothing about the thread itself. Michael's |> subsequent post about SocketTimeoutException reinforces that point. |> |> By the way, I think that in general you need to interpret the |> Javadoc for core classes in a broader sense than it seems. Older Javadoc |> (from version 1.0) used to mention implementation details that were not |> necessarily important and limited the applicability of the classes. |> Newer documentation tends to go out of its way to avoid mentioning such |> implementation detail and I believe that's a good thing. When |> InterruptedIOException was written, Thread.interrupt() was probably the |> only way to interrupt I/O operations. Nowadays there are others. Sun has |> generalized its meaning over time as evident by SocketTimeoutException. |> At least, that's my interpretation :) |> |> Gili |> |> Kustaa Nyholm wrote: |>>> I disagree with your interpretation. Read |>>> SocketTimeoutException to |>>> see |>>> what I mean. InterruptedIOException means the operation was interrupted, |>>> not necessarily by way of Thread.interrupt(). |>> Well SocketTimeoutException javadoc only says, very briefly: |>> |>> "Signals that a timeout has occurred on a socket read or accept." |>> |>> So that is not too helpful. But since it is derived from |>> InterruptedIOException my interpretation it that they have an 'is-a' |>> relationship and InterruptedIOException needs to honor the contract of |>> InterruptedIOException which says: |>> |>> "...because the thread performing it was interrupted." |>> |>> To me this very specifically talks about interrupting threads with |>> Thread.interrupt() |>> |>> |>>> Returning 0 in case of timeout sounds wrong to me because it |>>> is a |>>> legal |>>> byte value that could have been read. |>> Agreed, that's what I tried to say. 0 is a legal byte value for read() to |>> return so that cannot be used. For read read(byte[]) which returns the |>> number of bytes read 0 could be used but there again 0 can be returned |>> if 0 |>> byte[] size is 0. So there again 0 is not a good option. |>> |>>> Returning -1 also sounds wrong to |>>> me because this isn't strictly the end of stream. |>> Like I said, it isn't strictly the end of stream. But also does not |>> forbid treating it as (temporary) end of stream. |>> |>>> BufferedInputStream |>>> and others assume that once you reach the end of stream you will never |>>> see more data, ever. |>> Can you provide a reference for that. |>> |>>> As far as I know, the core APIs are written in |>>> terms of throwing InterruptedIOException for timeouts. |>> Would also like to see something to support that. |>> |>> |>> The behavior of throwing an exception on timeout is also a little bit |>> problematic, consider: |>> |>> byte buf[1000]; |>> int n=ins.read(buf); |>> // do something with the n bytes received |>> |>> What happens if a timeout occurs before we have received 1000 bytes? |>> |>> If an exception is thrown then the user of the read() needs to handle |>> the bytes received in two places or else those last <1000 bytes are lost. |>> A better solution would be to return the bytes received so far and throw |>> the exception on the next call (if any). But the main point is that |>> neither of these case obviously correct and neither is specified in the |>> javadocs. Where as a lot of code that just handles the return value |>> of read(byte[]) correctly works without any further ado. |>> |>> |>> |>> The main thing is that I think we should not break existing applications, |>> which I expect are not handling InterruptedIOException but many of |>> which may |>> depend on getting back -1 in case of timeouts. |>> |>> It has been a while since I used the javax.javacomm but I seem to recall |>> that it returned -1 and I think this is the defining standard. |>> |>> I expect most rxtx users are more interested in compatibility and |>> stability |>> than semantic niceties and improving the API. |>> |>> br Kusti |>> |>> |>> | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi, Maybe a better approach (improving the API) would be to consider implementing a NIO interface atop the underlying serial communication... ~ if someone desires the existing behavior, then they use a facade that lies atop of the NIO and provide the same quirks associated with it. As I see it, the implementation overrides the general contract of the InputStream to provide for the timeout functionality and it would be somewhat troublesome to expect a user of that API to catch subclasses of IOException. Best, Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoNv38ACgkQnQTBLXttTeWZ+wCeO4CTrI5l+vLPrjHl8fBj7FOL Ft8AnjQ7bXnvMhOlwZdK5CYAuoQeQ9u0 =QAax -----END PGP SIGNATURE----- From luis.moreira at ntlworld.com Sat May 2 00:39:04 2009 From: luis.moreira at ntlworld.com (luis.moreira at ntlworld.com) Date: Sat, 2 May 2009 7:39:04 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Hi Travis, The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. The issues I still have is the errors after that. Do you have any idea what can be causing this errors? _______________________________________________________________________________ conftest.c: In function 'main': conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) conftest.c:8: error: (Each undeclared identifier is reported only once conftest.c:8: error: for each function it appears in.) conftest.c:8: error: expected ')' before string constant conftest.c:8: warning: format not a string literal and no format arguments ./configure: line 21462: ./conftest: No such file or directory ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands ------------------------------------------------------------------------------- I don't know what happened to my previous post, it as not showed up in the list. Best Regards Luis From tjarvi at qbang.org Sat May 2 07:30:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 07:30:04 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> References: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Message-ID: On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > Hi Travis, > The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. > The issues I still have is the errors after that. Do you have any idea what can be causing this errors? > > _______________________________________________________________________________ > conftest.c: In function 'main': > conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) > conftest.c:8: error: (Each undeclared identifier is reported only once > conftest.c:8: error: for each function it appears in.) > conftest.c:8: error: expected ')' before string constant > conftest.c:8: warning: format not a string literal and no format arguments > ./configure: line 21462: ./conftest: No such file or directory > ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: config.h is unchanged > config.status: executing depfiles commands > ------------------------------------------------------------------------------- > > This was corrected in CVS. I think you can just do the following in the top directory: cvs login: (pw is mousy) cvs update That will get the current fixes. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sat May 2 16:14:50 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sat, 02 May 2009 23:14:50 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FCC5DA.6000700@ntlworld.com> Trent Jarvi wrote: > > > On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > >> Hi Travis, >> The problem with the Makefile is not a problem,When I run ./configure >> I make a new Makefile with the same data in it, hence what I just >> modified is removed. >> The issues I still have is the errors after that. Do you have any >> idea what can be causing this errors? >> >> _______________________________________________________________________________ >> >> conftest.c: In function 'main': >> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >> function) >> conftest.c:8: error: (Each undeclared identifier is reported only once >> conftest.c:8: error: for each function it appears in.) >> conftest.c:8: error: expected ')' before string constant >> conftest.c:8: warning: format not a string literal and no format >> arguments >> ./configure: line 21462: ./conftest: No such file or directory >> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >> expected >> configure: creating ./config.status >> config.status: creating Makefile >> config.status: creating config.h >> config.status: config.h is unchanged >> config.status: executing depfiles commands >> ------------------------------------------------------------------------------- >> >> >> > > This was corrected in CVS. I think you can just do the following in > the top directory: > > cvs login: (pw is mousy) > cvs update > > That will get the current fixes. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, apologies for the mix-up of your name. I managed to get further on by updating CVS, the configure command gets to the end without any errors, it still warns me that it is confused about where to find the jni_md.h but I just edited the Makefile and sorted that out. I then run make, with no parameters following the instructions on the Wiki, but that generated a few more errors: ----------------------------------------------------------------------------------------------------------------------- gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. -I/usr/lib/jvm/java-6-openjdk/include /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' undeclared (first use in this function) /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared identifier is reported only once /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each function it appears in.) libtool: link: `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 ----------------------------------------------------------------------------------------------------------------------- Another question I have is, in which folder will the .so files be placed after make finishes? thank you very much for your help. Best Regards Luis From tjarvi at qbang.org Sat May 2 19:27:08 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 19:27:08 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FCC5DA.6000700@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> Message-ID: On Sat, 2 May 2009, Luis Moreira wrote: > Trent Jarvi wrote: >> >> >> On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: >> >>> Hi Travis, >>> The problem with the Makefile is not a problem,When I run ./configure >>> I make a new Makefile with the same data in it, hence what I just >>> modified is removed. >>> The issues I still have is the errors after that. Do you have any >>> idea what can be causing this errors? >>> >>> _______________________________________________________________________________ >>> >>> conftest.c: In function 'main': >>> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >>> function) >>> conftest.c:8: error: (Each undeclared identifier is reported only once >>> conftest.c:8: error: for each function it appears in.) >>> conftest.c:8: error: expected ')' before string constant >>> conftest.c:8: warning: format not a string literal and no format >>> arguments >>> ./configure: line 21462: ./conftest: No such file or directory >>> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >>> expected >>> configure: creating ./config.status >>> config.status: creating Makefile >>> config.status: creating config.h >>> config.status: config.h is unchanged >>> config.status: executing depfiles commands >>> ------------------------------------------------------------------------------- >>> >>> >>> >> >> This was corrected in CVS. I think you can just do the following in >> the top directory: >> >> cvs login: (pw is mousy) >> cvs update >> >> That will get the current fixes. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > apologies for the mix-up of your name. > I managed to get further on by updating CVS, the configure command gets > to the end without any errors, it still warns me that it is confused > about where to find the jni_md.h but I just edited the Makefile and > sorted that out. > I then run make, with no parameters following the instructions on the > Wiki, but that generated a few more errors: > ----------------------------------------------------------------------------------------------------------------------- > > gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. > -I/usr/lib/jvm/java-6-openjdk/include > /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE > -D_BSD_SOURCE -D__need_timespec -c > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o > /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' > undeclared (first use in this function) > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared > identifier is reported only once > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each > function it appears in.) > libtool: link: > `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a > valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 > ----------------------------------------------------------------------------------------------------------------------- > > Another question I have is, in which folder will the .so files be placed > after make finishes? > > thank you very much for your help. > Ah when you do cvs update pass the -Pd option cvs update -Pd Also, when you run configure, use --disable-PRINTER to only build the serial support. It will make things easier. --disable-LOCKFILES will also be easier to get going until you want to learn about how to prevent multiple applications from reading the same serial port. The link for debugging will describe where the files go. By default, it will install in the JRE/JDK under jre/lib/ext (the jar file) jre/lib/i386 (the .so file) Those are on the proper paths when you use the sun or ibm jdk. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sun May 3 01:30:43 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sun, 03 May 2009 08:30:43 +0100 Subject: [Rxtx] First use of RXTX package In-Reply-To: References: <49FCC5DA.6000700@ntlworld.com> Message-ID: <49FD4823.5080204@ntlworld.com> Ah > > when you do cvs update pass the -Pd option > > cvs update -Pd > > Also, when you run configure, use --disable-PRINTER to only build the > serial support. It will make things easier. --disable-LOCKFILES will > also be easier to get going until you want to learn about how to > prevent multiple applications from reading the same serial port. > > The link for debugging will describe where the files go. By default, > it will install in the JRE/JDK under > > jre/lib/ext (the jar file) > jre/lib/i386 (the .so file) > > Those are on the proper paths when you use the sun or ibm jdk. > > http://rxtx.qbang.org/wiki/index.php/Trouble_shooting > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, It as done it! I think this instructions you gave me should be on the Wiki, I can write them for you if you like. Also on the Wiki when you describe the three methods of installing the RxTx package it is confusing because as far as I can see, you always have to do method 1 or the .so files will not be generated(is this correct?). Then you can if you like change the location with method 1 & 2. Is it possible to modify the .la file to point to different directories for installation and then you can decide where to place the files? In a way I have learned quite a lot about Linux by having to struggle, with your help, to find solutions to the problems I encountered (I am still very new to Linux), but maybe we need to log these problems somewhere to make it less of a struggle for others like me. I have used the PortLister example to test it and it came up with my USB to dual Serial adaptor Ports. I will now explore the RxTx package, before I tackle the windows installation, I will let you know of my experience. Thank you for all your Help. Best Regards Luis From tjarvi at qbang.org Sun May 3 10:37:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 3 May 2009 10:37:50 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FD4823.5080204@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> <49FD4823.5080204@ntlworld.com> Message-ID: On Sun, 3 May 2009, Luis Moreira wrote: > Ah >> >> when you do cvs update pass the -Pd option >> >> cvs update -Pd >> >> Also, when you run configure, use --disable-PRINTER to only build the >> serial support. It will make things easier. --disable-LOCKFILES will >> also be easier to get going until you want to learn about how to >> prevent multiple applications from reading the same serial port. >> >> The link for debugging will describe where the files go. By default, >> it will install in the JRE/JDK under >> >> jre/lib/ext (the jar file) >> jre/lib/i386 (the .so file) >> >> Those are on the proper paths when you use the sun or ibm jdk. >> >> http://rxtx.qbang.org/wiki/index.php/Trouble_shooting >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > It as done it! > I think this instructions you gave me should be on the Wiki, I can write > them for you if you like. Also on the Wiki when you describe the three > methods of installing the RxTx package it is confusing because as far > as I can see, you always have to do method 1 or the .so files will not > be generated(is this correct?). Then you can if you like change the > location with method 1 & 2. Is it possible to modify the .la file to > point to different directories for installation and then you can decide > where to place the files? > In a way I have learned quite a lot about Linux by having to struggle, > with your help, to find solutions to the problems I encountered (I am > still very new to Linux), but maybe we need to log these problems > somewhere to make it less of a struggle for others like me. > > I have used the PortLister example to test it and it came up with my USB > to dual Serial adaptor Ports. > > I will now explore the RxTx package, before I tackle the windows > installation, I will let you know of my experience. > > Thank you for all your Help. > Hi Luis, The locations suggested for first time configuration could be documented in a new wiki page explaining that this is not the recommended general workflow but does help new users that are not worried about having rxtx installed into the JRE. For a professional environment, the user would want to follow the workflow currently on the wiki and keep their JRE clean. Often the user will not be able to add libraries to the JRE and will need to use their home directory or a sandbox. Feel free to add information to the wiki. I'd suggest creating comment in the current page and have the comment link to what worked for you as a first time user new to Linux. You can create a new page with your comments. In the long term, we will be working on an autoinstaller that works over the web. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Mon May 4 09:15:40 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Mon, 04 May 2009 16:15:40 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FF069C.8040406@ntlworld.com> Hi Trent, I have now installed the package on my 64 bit machine and when I run my program I get errors on the attachment. I know it as something to do with the architecture of my system but I can no figure out how to fix it. I have built it from source again, I did not transfer the files from machine to machine. can you please put me in the right direction. Thank you very much for your help. Best Regards Luis -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshoot.png Type: image/png Size: 25753 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090504/141ab5dc/attachment-0014.png From johnny.luong at trustcommerce.com Mon May 4 11:57:08 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 04 May 2009 10:57:08 -0700 Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FF069C.8040406@ntlworld.com> References: <49FF069C.8040406@ntlworld.com> Message-ID: <49FF2C74.90805@trustcommerce.com> Luis Moreira wrote: > Hi Trent, > I have now installed the package on my 64 bit machine and when I run my > program I get errors on the attachment. I know it as something to do > with the architecture of my system but I can no figure out how to fix > it. I have built it from source again, I did not transfer the files from > machine to machine. > can you please put me in the right direction. > Thank you very much for your help. > Best Regards > Luis > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Hi, Does running it on a 64-bit JVM help? Your host environment might be building objects for a 64-bit environment unless you did a cross-compile... -- you can find out by doing something like the following: johnny at spike:~$ java -version java version "1.6.0_0" OpenJDK Runtime Environment (build 1.6.0_0-b11) OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode) johnny at spike:~$ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) -Johnny From huangdongkai at gmail.com Wed May 6 11:06:06 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 01:06:06 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. Message-ID: Dear all, I recompile the rxtxSerial source code by MinGW32 and compile success. But when I run my Application which use rxtxSerial.dll to communicate with serial port, a runtime exception happened and application crash. I have no idea why it can not work, beacuse i have not change any source code of rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I have missed when compile the source code on Window NT? Here below is the output error massage. # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, tid=1360 # # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing windows-x86) # Problematic frame: # V [jvm.dll+0x1b6824] # # An error report file with more information is saved as: # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/32c1e699/attachment-0012.html From tjarvi at qbang.org Wed May 6 20:04:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 May 2009 20:04:10 -0600 (MDT) Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: On Thu, 7 May 2009, dongkai huang wrote: > Dear all, > ????? I recompile the rxtxSerial source code by MinGW32 and compile success. > But when I run my Application which use rxtxSerial.dll to communicate with > serial port, a runtime exception happened and application crash.? I have no > idea why it can not work, beacuse i have not change any source code of > rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I > have missed when compile the source code on Window NT? Here below is the > output error massage. > # > # An unexpected error has been detected by Java Runtime Environment: > # > #? EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, > tid=1360 > # > # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing > windows-x86) > > # Problematic frame: > # V? [jvm.dll+0x1b6824] > # > # An error report file with more information is saved as: > # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log > # > # If you would like to submit a bug report, please visit: > #?? http://java.sun.com/webapps/bugreport/crash.jsp > # > > > Hi Dongkai Could you explain how you compiled rxtx with mingw? Did you run configure? Was the compiler native or a cross compiler (like compiling on Linux for Windows)? Is the crash happening when you first open the port or is it happening randomly later on? -- Trent Jarvi tjarvi at qbang.org From huangdongkai at gmail.com Wed May 6 20:48:56 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 10:48:56 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Hi Trent, I was followed the step on INSTALL file, did not run the configure, I used the Makefile.mingw32 which include on the source code package, and only change some path( jdk home path etc.). And I use the native compiler on Windows. The crash happened on I call the getPortIdentifiers() every time. On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Dear all, >> I recompile the rxtxSerial source code by MinGW32 and compile >> success. >> But when I run my Application which use rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and application crash. I have >> no >> idea why it can not work, beacuse i have not change any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing >> I >> have missed when compile the source code on Window NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is saved as: >> # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> > Hi Dongkai > > Could you explain how you compiled rxtx with mingw? Did you run configure? > Was the compiler native or a cross compiler (like compiling on Linux for > Windows)? > > Is the crash happening when you first open the port or is it happening > randomly later on? > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/733eded5/attachment-0012.html From m.j.tandy at warwick.ac.uk Thu May 7 10:39:12 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 7 May 2009 17:39:12 +0100 Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. Message-ID: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> I've encountered a bug in how XON/XOFF are handled on Windows. The symptoms were: 1. XON/XOFF from device to PC did not stop transmission. 2. XON/XOFF characters were present in data read from serial port input stream, when it was expected that they would be stripped out. 3. Investigation with SysInternals PortMon revealed the following configuration when using rxtx: 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 while HyperTerminal, which did not have the same problems as me, produced the following: 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 In other words, the problem is that, in addition to being told to use XON/XOFF flow control, the computer has to explicitly be told which characters to use for 'XON' and 'XOFF'. This part of the configuration was being missed out. I got the latest rxtx source from CVS, and identified the problem as an omission in the 'init_termios' function of 'termios.c', which configures the unix/termios 'c_cc' (control characters) data structure - but omits to configure the VSTART and VSTOP control characters. Later, the termios c_cc data structure is translated (by termios_to_DCB) into a data structure named 'DCB', which is passed to the windows serial port configuration interface. By adding two lines defining the standard XON/XOFF characters to the function init_termios, the bug is fixed. A patch doing this is attached. Thanks, Michael Tandy -------------- next part -------------- A non-text attachment was scrubbed... Name: xon-xoff.diff Type: application/octet-stream Size: 667 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/159c0dcc/attachment-0011.obj From tjarvi at qbang.org Thu May 7 17:57:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 May 2009 17:57:28 -0600 (MDT) Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. In-Reply-To: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> References: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> Message-ID: On Thu, 7 May 2009, Michael Tandy wrote: > I've encountered a bug in how XON/XOFF are handled on Windows. > > The symptoms were: > 1. XON/XOFF from device to PC did not stop transmission. > 2. XON/XOFF characters were present in data read from serial port > input stream, when it was expected that they would be stripped out. > 3. Investigation with SysInternals PortMon revealed the following > configuration when using rxtx: > > 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 > BRK:0 EVT:a XON:0 XOFF:0 > > while HyperTerminal, which did not have the same problems as me, > produced the following: > > 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 > > In other words, the problem is that, in addition to being told to use > XON/XOFF flow control, the computer has to explicitly be told which > characters to use for 'XON' and 'XOFF'. This part of the configuration > was being missed out. > > I got the latest rxtx source from CVS, and identified the problem as > an omission in the 'init_termios' function of 'termios.c', which > configures the unix/termios 'c_cc' (control characters) data structure > - but omits to configure the VSTART and VSTOP control characters. > Later, the termios c_cc data structure is translated (by > termios_to_DCB) into a data structure named 'DCB', which is passed to > the windows serial port configuration interface. > > By adding two lines defining the standard XON/XOFF characters to the > function init_termios, the bug is fixed. A patch doing this is > attached. > Thanks Michael, Good timing. I plan on releasing rxtx-2.2 this coming Sunday. -- Trent Jarvi tjarvi at qbang.org From wjr at weru.ksu.edu Fri May 8 11:38:29 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Fri, 08 May 2009 12:38:29 -0500 Subject: [Rxtx] swing jfilechooser lockup Message-ID: <4A046E15.6010907@weru.ksu.edu> Hi, I wrote a small swing app to download images from an industrial camera. I used the two way serial sample code as a starting point. The app works fine EXCEPT for a call to jfilechooser. After I open the comm port and then try to change the output directory or log file, the jfilechooser winds up trying to unpark (note, parking is not something I'm really familiar with) and doesn't. If I try to change the file or directory before I start the comm port, it works. If I click on menu items that don't call jfilechooser, everything is OK. If I try closing the comm port and then try to create a jfilechooser, it locks up. There is obviously some sort of deadlock here because the awt thread starts waiting on something but it's not clear what. I haven't gone thru the rxtx code yet because it's not in the file structure that netbeans wants for debugging purposes. However, debugging code that I don't have a clear idea of what it is supposed to do is not my idea of a good time. Does anyone have any ideas on what is going on here? Thanks, wjr From Bob_Jacobsen at lbl.gov Fri May 8 14:48:25 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Fri, 8 May 2009 13:48:25 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A046E15.6010907@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> Message-ID: At 12:38 PM -0500 5/8/09, Bill Rust wrote: >Hi, > >I wrote a small swing app to download images from an industrial camera. >I used the two way serial sample code as a starting point. The app works >fine EXCEPT for a call to jfilechooser. After I open the comm port and >then try to change the output directory or log file, the jfilechooser >winds up trying to unpark (note, parking is not something I'm really >familiar with) and doesn't. If I try to change the file or directory >before I start the comm port, it works. If I click on menu items that >don't call jfilechooser, everything is OK. If I try closing the comm >port and then try to create a jfilechooser, it locks up. There is >obviously some sort of deadlock here because the awt thread starts >waiting on something but it's not clear what. I haven't gone thru the >rxtx code yet because it's not in the file structure that netbeans wants >for debugging purposes. However, debugging code that I don't have a >clear idea of what it is supposed to do is not my idea of a good time. What is the threading structure of your code? The various high-function Swing components, such as JFileChooser, are notorious for doing Really Bad Stuff when invoked from off the Swing thread. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From bschlining at gmail.com Fri May 8 15:08:50 2009 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 8 May 2009 14:08:50 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: Bob's probably right...take look at javax.swing.SwingUtilites for the workaround to get your swing stuff invoked on the EventDispatchThread (EDT). Some swing-methods do work when called outside of the EDT, but just to be safe, do your creation and swing calls on the EDT. It's really simple, here's an example of a synchronous call. // Here's how to run stuff on the EDT from a different thread SwingUtilities.invokeAndWait(new Runnable() { public void run() { JFileChooser fc; // create, setup, show your filechooser // Get the result from the filechooser } }); To do a asynchronous call use SwingUtilities.invokeLater > >I wrote a small swing app to download images from an industrial camera. > >I used the two way serial sample code as a starting point. The app works > >fine EXCEPT for a call to jfilechooser. After I open the comm port and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090508/c21c2127/attachment-0010.html From tod at todbot.com Fri May 8 16:27:12 2009 From: tod at todbot.com (Tod E. Kurt) Date: Fri, 8 May 2009 15:27:12 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> This is the exact technique I use to let the user choose which serial port to use on startup. Here's a method I've got in many of my sketches: void choosePort() { String portlist[] = Serial.list(); String port = null; javax.swing.SwingUtilities.invokeLater(new Runnable() { public void run() { try { String port = (String) javax.swing.JOptionPane.showInputDialog( null, "Select Serial Port", "MySuperSketch", javax.swing.JOptionPane.QUESTION_MESSAGE, null, portlist, null); if( port == null ) { javax.swing.JOptionPane.showMessageDialog(null, "No port chosen, goodbye"); System.exit(1); } serialPort = port; } catch (Exception e) { e.printStackTrace(); } } } ); } On May 8, 2009, at 2:08 p, Brian Schlining wrote: > Bob's probably right...take look at javax.swing.SwingUtilites for > the workaround to get your swing stuff invoked on the > EventDispatchThread (EDT). Some swing-methods do work when called > outside of the EDT, but just to be safe, do your creation and swing > calls on the EDT. It's really simple, here's an example of a > synchronous call. > > // Here's how to run stuff on the EDT from a different thread > SwingUtilities.invokeAndWait(new Runnable() { > public void run() { > JFileChooser fc; // create, setup, show your filechooser > // Get the result from the filechooser > } > }); > > To do a asynchronous call use SwingUtilities.invokeLater > > > >I wrote a small swing app to download images from an industrial > camera. > >I used the two way serial sample code as a starting point. The app > works > >fine EXCEPT for a call to jfilechooser. After I open the comm port > and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From huangdongkai at gmail.com Sat May 9 04:46:22 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Sat, 9 May 2009 18:46:22 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Dear Trent, After I intsall the ming32-cross compile to compile the rxtxSerial.dll and testing, i found the same problem still exist. I am not sure my compiler version is the same as your's. Could you tell me the way you can success compile rxtx-2.1-7r2 release source code? Thanks for you kindly help. On Fri, May 8, 2009 at 8:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Hi Trent, >> The attach is the Make file I use to compile the rxtx. >> >> On Thu, May 7, 2009 at 10:48 AM, dongkai huang >> wrote: >> Hi Trent, >> I was followed the step on INSTALL file, did not run the >> configure, I used the Makefile.mingw32 which include on the >> source code package, and only change some path( jdk home path >> etc.). And I use the native compiler on Windows. >> The crash happened on I call the getPortIdentifiers() >> every time. >> >> On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: >> >> >> On Thu, 7 May 2009, dongkai huang wrote: >> >> Dear all, >> I recompile the rxtxSerial source code by >> MinGW32 and compile success. >> But when I run my Application which use >> rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and >> application crash. I have no >> idea why it can not work, beacuse i have not change >> any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source >> code. Did some thing I >> have missed when compile the source code on Window >> NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java >> Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at >> pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 >> mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is >> saved as: >> # >> D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please >> visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> >> Hi Dongkai >> >> Could you explain how you compiled rxtx with mingw? Did you run >> configure? Was the compiler native or a cross compiler (like >> compiling on Linux for Windows)? >> >> Is the crash happening when you first open the port or is it >> happening randomly later on? >> >> > Thanks Dongkai > > I'll look at your Makefile tomorrow. Which version of mingw was this? > > I suspect there is a problem with that makefile. I usually built that > version of rxtx for windows with a mingw32 cross compiler using the > configure script. > > The configure script may well work for you if you have a cygwin environment > with mingw instead of gcc. I'll take a look at what is different. > > -- > > Trent Jarvi > tjarvi at qbang.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090509/b729c429/attachment-0010.html From wjr at weru.ksu.edu Wed May 13 15:50:30 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Wed, 13 May 2009 16:50:30 -0500 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> Message-ID: <4A0B40A6.5070204@weru.ksu.edu> Tod's solution misses the point. He is picking and opening the serial port. That's the step before where my problem occurs. To recap: 1. I have a simple java swing app. 2. On the menu bar, there is the standard set, file, etc., of jmenu's. Under file, there is a jmenuitem, logfileopen, which pops up a jfilechooser to select a logfile and another jmenuitem, setprefix, which pops up a jdialog to allow the user to type in a file name prefix for downloaded images. 3. There is another jmenuitem that starts the commport running. 4. When logfileopen is pressed before the commport is started, it works. 5. When logfileopen is pressed after the commport is started, it hangs. 6. setprefix works whether or not the commport is started. 7. portIdentifier.open starts a thread that goes into a native method, RXTXPort.eventLoop, and never returns. 8. java.sun bugs has a bug report, 6741890, that is similar but their workaround doesn't. 9. When it locks up, there is a swing-shell thread that appears to be down in some native libraries, winshellfolder2 10. The awt-eventQ thread is unblocked but in code that says its parked. If you have anymore ideas, I'd really appreciate them. wjr Tod E. Kurt wrote: > This is the exact technique I use to let the user choose which serial > port to use on startup. Here's a method I've got in many of my sketches: > > void choosePort() { > String portlist[] = Serial.list(); > String port = null; > javax.swing.SwingUtilities.invokeLater(new Runnable() { > public void run() { > try { > String port = (String) javax.swing.JOptionPane.showInputDialog( > null, > "Select Serial Port", > "MySuperSketch", > javax.swing.JOptionPane.QUESTION_MESSAGE, > null, portlist, null); > if( port == null ) { > javax.swing.JOptionPane.showMessageDialog(null, "No port > chosen, goodbye"); > System.exit(1); > } > serialPort = port; > } > catch (Exception e) { > e.printStackTrace(); > } > } > } ); > } > > > On May 8, 2009, at 2:08 p, Brian Schlining wrote: > >> Bob's probably right...take look at javax.swing.SwingUtilites for the >> workaround to get your swing stuff invoked on the EventDispatchThread >> (EDT). Some swing-methods do work when called outside of the EDT, but >> just to be safe, do your creation and swing calls on the EDT. It's >> really simple, here's an example of a synchronous call. >> >> // Here's how to run stuff on the EDT from a different thread >> SwingUtilities.invokeAndWait(new Runnable() { >> public void run() { >> JFileChooser fc; // create, setup, show your filechooser >> // Get the result from the filechooser >> } >> }); >> >> To do a asynchronous call use SwingUtilities.invokeLater >> >> >> >I wrote a small swing app to download images from an industrial camera. >> >I used the two way serial sample code as a starting point. The app works >> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >> >then try to change the output directory or log file, the jfilechooser >> >winds up trying to unpark (note, parking is not something I'm really >> >familiar with) and doesn't. >> What is the threading structure of your code? >> >> The various high-function Swing components, such as JFileChooser, are >> notorious for doing Really Bad Stuff when invoked from off the Swing >> thread. >> >> Bob >> -- >> Bob Jacobsen, UC Berkeley >> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >> JacobsenRG >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -- >> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >> Brian Schlining >> bschlining at gmail.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx From m.j.tandy at warwick.ac.uk Wed May 13 16:42:24 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 13 May 2009 23:42:24 +0100 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A0B40A6.5070204@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> <4A0B40A6.5070204@weru.ksu.edu> Message-ID: <302aa0340905131542i601ec3f1w3b0b5879c23f8eca@mail.gmail.com> Perhaps you could post your program, or an excerpt of it sufficient to demonstrate the problem you're having, for us to have a look at? 2009/5/13 Bill Rust : > Tod's solution misses the point. He is picking and opening the serial > port. That's the step before where my problem occurs. > > To recap: > > 1. I have a simple java swing app. > 2. On the menu bar, there is the standard set, file, etc., of jmenu's. > Under file, there is a jmenuitem, logfileopen, which pops up a > jfilechooser to select a logfile and another jmenuitem, setprefix, which > pops up a jdialog to allow the user to type in a file name prefix for > downloaded images. > 3. There is another jmenuitem that starts the commport running. > 4. When logfileopen is pressed before the commport is started, it works. > 5. When logfileopen is pressed after the commport is started, it hangs. > 6. setprefix works whether or not the commport is started. > 7. portIdentifier.open starts a thread that goes into a native > method, ? ? ? ? ? ? ? ? ? ? ? ? RXTXPort.eventLoop, and never returns. > 8. java.sun bugs has a bug report, 6741890, that is similar but > their ? ? ? ? ? ? ? ? ? workaround doesn't. > 9. When it locks up, there is a swing-shell thread that appears to be > ? ? ? ?down in some native libraries, winshellfolder2 > 10. The awt-eventQ thread is unblocked but in code that says its parked. > > If you have anymore ideas, I'd really appreciate them. > > wjr > > Tod E. Kurt wrote: >> This is the exact technique I use to let the user choose which serial >> port to use on startup. ?Here's a method I've got in many of my sketches: >> >> void choosePort() { >> ? String portlist[] = Serial.list(); >> ? String port = null; >> ? javax.swing.SwingUtilities.invokeLater(new Runnable() { >> ? ? public void run() { >> ? ? ? try { >> ? ? ? ? String port = (String) javax.swing.JOptionPane.showInputDialog( >> null, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Select Serial Port", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "MySuperSketch", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? javax.swing.JOptionPane.QUESTION_MESSAGE, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? null, portlist, null); >> ? ? ? ? if( port == null ) ?{ >> ? ? ? ? ? javax.swing.JOptionPane.showMessageDialog(null, "No port >> chosen, goodbye"); >> ? ? ? ? ? System.exit(1); >> ? ? ? ? } >> ? ? ? ? serialPort = port; >> ? ? ? } >> ? ? ? catch (Exception e) { >> ? ? ? ? e.printStackTrace(); >> ? ? ? } >> ? ? } >> ? } ); >> } >> >> >> On May 8, 2009, at 2:08 p, Brian Schlining wrote: >> >>> Bob's probably right...take look at javax.swing.SwingUtilites for the >>> workaround to get your swing stuff invoked on the EventDispatchThread >>> (EDT). Some swing-methods do work when called outside of the EDT, but >>> just to be safe, do your creation and swing calls on the EDT. It's >>> really simple, here's an example of a synchronous call. >>> >>> // Here's how to run stuff on the EDT from a different thread >>> SwingUtilities.invokeAndWait(new Runnable() { >>> ? ? ? public void run() { >>> ? ? ? ? ? ?JFileChooser fc; // create, setup, show your filechooser >>> ? ? ? ? ? ?// Get the result from the filechooser >>> ? ? ? } >>> }); >>> >>> To do a asynchronous call use SwingUtilities.invokeLater >>> >>> >>> >I wrote a small swing app to download images from an industrial camera. >>> >I used the two way serial sample code as a starting point. The app works >>> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >>> >then try to change the output directory or log file, the jfilechooser >>> >winds up trying to unpark (note, parking is not something I'm really >>> >familiar with) and doesn't. >>> What is the threading structure of your code? >>> >>> The various high-function Swing components, such as JFileChooser, are >>> notorious for doing Really Bad Stuff when invoked from off the Swing >>> thread. >>> >>> Bob >>> -- >>> Bob Jacobsen, UC Berkeley >>> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >>> JacobsenRG >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >>> -- >>> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >>> Brian Schlining >>> bschlining at gmail.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From m.j.tandy at warwick.ac.uk Thu May 14 03:05:36 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 14 May 2009 10:05:36 +0100 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A0B40A6.5070204@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> <4A0B40A6.5070204@weru.ksu.edu> Message-ID: <302aa0340905140205p6ceb5a9br24e00a50e9cafa5@mail.gmail.com> Java has a built in deadlock detection utility; run your program from the command line, then (on windows) press Ctrl+Break (On Linux, Ctrl+\ does the trick I'm told). That should produce status information and a stack trace for every running thread, including locks held and locks waited on. Maybe that would contain enough information for you to work out what's locking what? 2009/5/13 Bill Rust : > Tod's solution misses the point. He is picking and opening the serial > port. That's the step before where my problem occurs. > > To recap: > > 1. I have a simple java swing app. > 2. On the menu bar, there is the standard set, file, etc., of jmenu's. > Under file, there is a jmenuitem, logfileopen, which pops up a > jfilechooser to select a logfile and another jmenuitem, setprefix, which > pops up a jdialog to allow the user to type in a file name prefix for > downloaded images. > 3. There is another jmenuitem that starts the commport running. > 4. When logfileopen is pressed before the commport is started, it works. > 5. When logfileopen is pressed after the commport is started, it hangs. > 6. setprefix works whether or not the commport is started. > 7. portIdentifier.open starts a thread that goes into a native > method, ? ? ? ? ? ? ? ? ? ? ? ? RXTXPort.eventLoop, and never returns. > 8. java.sun bugs has a bug report, 6741890, that is similar but > their ? ? ? ? ? ? ? ? ? workaround doesn't. > 9. When it locks up, there is a swing-shell thread that appears to be > ? ? ? ?down in some native libraries, winshellfolder2 > 10. The awt-eventQ thread is unblocked but in code that says its parked. > > If you have anymore ideas, I'd really appreciate them. > > wjr > > Tod E. Kurt wrote: >> This is the exact technique I use to let the user choose which serial >> port to use on startup. ?Here's a method I've got in many of my sketches: >> >> void choosePort() { >> ? String portlist[] = Serial.list(); >> ? String port = null; >> ? javax.swing.SwingUtilities.invokeLater(new Runnable() { >> ? ? public void run() { >> ? ? ? try { >> ? ? ? ? String port = (String) javax.swing.JOptionPane.showInputDialog( >> null, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Select Serial Port", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "MySuperSketch", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? javax.swing.JOptionPane.QUESTION_MESSAGE, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? null, portlist, null); >> ? ? ? ? if( port == null ) ?{ >> ? ? ? ? ? javax.swing.JOptionPane.showMessageDialog(null, "No port >> chosen, goodbye"); >> ? ? ? ? ? System.exit(1); >> ? ? ? ? } >> ? ? ? ? serialPort = port; >> ? ? ? } >> ? ? ? catch (Exception e) { >> ? ? ? ? e.printStackTrace(); >> ? ? ? } >> ? ? } >> ? } ); >> } >> >> >> On May 8, 2009, at 2:08 p, Brian Schlining wrote: >> >>> Bob's probably right...take look at javax.swing.SwingUtilites for the >>> workaround to get your swing stuff invoked on the EventDispatchThread >>> (EDT). Some swing-methods do work when called outside of the EDT, but >>> just to be safe, do your creation and swing calls on the EDT. It's >>> really simple, here's an example of a synchronous call. >>> >>> // Here's how to run stuff on the EDT from a different thread >>> SwingUtilities.invokeAndWait(new Runnable() { >>> ? ? ? public void run() { >>> ? ? ? ? ? ?JFileChooser fc; // create, setup, show your filechooser >>> ? ? ? ? ? ?// Get the result from the filechooser >>> ? ? ? } >>> }); >>> >>> To do a asynchronous call use SwingUtilities.invokeLater >>> >>> >>> >I wrote a small swing app to download images from an industrial camera. >>> >I used the two way serial sample code as a starting point. The app works >>> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >>> >then try to change the output directory or log file, the jfilechooser >>> >winds up trying to unpark (note, parking is not something I'm really >>> >familiar with) and doesn't. >>> What is the threading structure of your code? >>> >>> The various high-function Swing components, such as JFileChooser, are >>> notorious for doing Really Bad Stuff when invoked from off the Swing >>> thread. >>> >>> Bob >>> -- >>> Bob Jacobsen, UC Berkeley >>> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >>> JacobsenRG >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >>> -- >>> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >>> Brian Schlining >>> bschlining at gmail.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From cowwoc at bbs.darktech.org Fri May 15 07:18:29 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 09:18:29 -0400 Subject: [Rxtx] InputStream timeouts Message-ID: <4A0D6BA5.8020209@bbs.darktech.org> Why does InputStream.read() return -1 on timeout instead of throwing InterruptedIOException which has existed specifically for this purpose since JDK 1.0? Sockets throw SocketTimeoutException which extends InterruptedIOException. I suspect that this logic confuses BufferedInputStream as well as end-users. Can we introduce this change along with the other timeout-related changes? Gili From Steffen.DETTMER at ingenico.com Fri May 15 07:36:19 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 15 May 2009 15:36:19 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0D6BA5.8020209@bbs.darktech.org> References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <20090515133619.GC17036@elberon.bln.de.ingenico.com> * cowwoc wrote on Fri, May 15, 2009 at 09:18 -0400: > Why does InputStream.read() return -1 on timeout shouldn't it block and only avialable() should care about timeouts? That is how I understand `This method blocks until input data is available' from: http://java.sun.com/j2se/1.5.0/docs/api/java/io/InputStream.html#read() public abstract int read() throws IOException Reads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. A subclass must provide an implementation of this method. Returns: the next byte of data, or -1 if the end of the stream is reached. Throws: IOException - if an I/O error occurs. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Fri May 15 08:22:19 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 15 May 2009 17:22:19 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: >From the javadoc for InputStream: "If no byte is available because the end of the stream has been reached, the value -1 is returned." Since character timeout is not an indication of EOF condition I guess one could argue that 0 should be returned in case of timeout. On the other hand one could also argue that since no data was available (if it timed out) the serial port input stream was at the end of stream (albeit possibly temporarily only). Further the javadoc seems to forbid the return value 0 for Inputstream.read(): " This method blocks until input data is available, the end of the stream is detected, or an exception is thrown." So it can return n >= 1 , -1 or throw an exception. InputStream.read(byte[]) can return 0 but for consistency the options with the other read methods the return value for timeout needs to be -1 or an exception. It goes against my grain to think that I get an exception when I've set up a timeout and I am thus expecting a timeout to happen sometimes. So it is not an exceptional case but expected situation in which case a special return value is philosophically speaking more appropriate. So I'm against changing this behavior. I expect a lot of code depend on the -1 or at least on not getting an exception when a timeout occurs. In any case if an exception were to be thrown it should *not* be InterruptedIOException. >From the javadoc for InterruptedIOException: "An InterruptedIOException is thrown to indicate that an input or output transfer has been terminated because the thread performing it was interrupted. The field bytesTransferred indicates how many bytes were successfully transferred before the interruption occurred" I do not think this matches the case for serial port receive character timeout. I read the javadoc above so that I get this exception when the thread in my code that is performing a read or write operation gets interrupted by Thread.interrupt(). And this is used to handle exactly that case: being able to gracefully and cleanly interrupt threads. my 2 snt worth br Kusti > From: cowwoc > Date: Fri, 15 May 2009 16:18:29 +0300 > To: rxtx > Conversation: [Rxtx] InputStream timeouts > Subject: [Rxtx] InputStream timeouts > > > > Why does InputStream.read() return -1 on timeout instead of > throwing InterruptedIOException which has existed specifically for this > purpose since JDK 1.0? Sockets throw SocketTimeoutException which > extends InterruptedIOException. I suspect that this logic confuses > BufferedInputStream as well as end-users. Can we introduce this change > along with the other timeout-related changes? > > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From cowwoc at bbs.darktech.org Fri May 15 08:35:27 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 10:35:27 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <4A0D7DAF.5030705@bbs.darktech.org> I disagree with your interpretation. Read SocketTimeoutException to see what I mean. InterruptedIOException means the operation was interrupted, not necessarily by way of Thread.interrupt(). Returning 0 in case of timeout sounds wrong to me because it is a legal byte value that could have been read. Returning -1 also sounds wrong to me because this isn't strictly the end of stream. BufferedInputStream and others assume that once you reach the end of stream you will never see more data, ever. As far as I know, the core APIs are written in terms of throwing InterruptedIOException for timeouts. Gili Kustaa Nyholm wrote: > >>From the javadoc for InputStream: > > "If no byte is available because the end of the stream has been reached, the > value -1 is returned." > > > Since character timeout is not an indication of EOF condition I guess one > could argue that 0 should be returned in case of timeout. On the other hand > one could also argue that since no data was available (if it timed out) the > serial port input stream was at the end of stream (albeit possibly > temporarily only). Further the javadoc seems to forbid the return value 0 > for Inputstream.read(): > > " This method blocks until input data is available, the end of the stream is > detected, or an exception is thrown." > > So it can return n >= 1 , -1 or throw an exception. InputStream.read(byte[]) > can return 0 but for consistency the options with the other read methods the > return value for timeout needs to be -1 or an exception. > > It goes against my grain to think that I get an exception when I've set up a > timeout and I am thus expecting a timeout to happen sometimes. So it is not > an exceptional case but expected situation in which case a special return > value is philosophically speaking more appropriate. > > So I'm against changing this behavior. I expect a lot of code depend on the > -1 or at least on not getting an exception when a timeout occurs. > > In any case if an exception were to be thrown it should *not* be > InterruptedIOException. > >>From the javadoc for InterruptedIOException: > > > "An InterruptedIOException is thrown to indicate that an input or output > transfer has been terminated because the thread performing it was > interrupted. The field bytesTransferred indicates how many bytes were > successfully transferred before the interruption occurred" > > I do not think this matches the case for serial port receive character > timeout. I read the javadoc above so that I get this exception when the > thread in my code that is performing a read or write operation gets > interrupted by Thread.interrupt(). And this is used to handle exactly that > case: being able to gracefully and cleanly interrupt threads. > > > > my 2 snt worth br Kusti > > > > >> From: cowwoc >> Date: Fri, 15 May 2009 16:18:29 +0300 >> To: rxtx >> Conversation: [Rxtx] InputStream timeouts >> Subject: [Rxtx] InputStream timeouts >> >> >> >> Why does InputStream.read() return -1 on timeout instead of >> throwing InterruptedIOException which has existed specifically for this >> purpose since JDK 1.0? Sockets throw SocketTimeoutException which >> extends InterruptedIOException. I suspect that this logic confuses >> BufferedInputStream as well as end-users. Can we introduce this change >> along with the other timeout-related changes? >> >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From m.j.tandy at warwick.ac.uk Fri May 15 09:17:36 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Fri, 15 May 2009 16:17:36 +0100 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <302aa0340905150817o39812d7y1b896004a2dcc2ab@mail.gmail.com> > I disagree with your interpretation. Read SocketTimeoutException to see > what I mean. InterruptedIOException means the operation was interrupted, > not necessarily by way of Thread.interrupt(). Strangely enough, the javadoc for InterruptedIOException says: "An InterruptedIOException is thrown to indicate that an input or output transfer has been terminated because the thread performing it was interrupted."[1] But the subclass SocketTimeoutException is used differently - here's an example from sun.net.httpserver.request: /** * block() only called when available==0 and buf is empty */ private synchronized void block () throws IOException { long currtime = server.getTime(); long maxtime = currtime + readTimeout; while (currtime < maxtime) { if (selector.select (readTimeout) == 1) { selector.selectedKeys().clear(); available (); return; } currtime = server.getTime(); } throw new SocketTimeoutException ("no data received"); } So it seems that SocketTimeoutExceptions get thrown not upon thread interruptions, but a certain time after a blocking read is started. [1] http://java.sun.com/javase/6/docs/api/java/io/InterruptedIOException.html From cowwoc at bbs.darktech.org Fri May 15 11:06:53 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 13:06:53 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0DA0F4.9050203@bbs.darktech.org> References: <4A0DA0F4.9050203@bbs.darktech.org> Message-ID: <4A0DA12D.2050303@bbs.darktech.org> Forgot to CC the list. Gili cowwoc wrote: > > "Thread was interrupted" does not necessarily mean > Thread.interrupt(). It just means that the operation (run by the thread) > was interrupted. If you read the beginning sentence for > InterruptedIOException it reads "Signals that an I/O operation has been > interrupted". This says nothing about the thread itself. Michael's > subsequent post about SocketTimeoutException reinforces that point. > > By the way, I think that in general you need to interpret the > Javadoc for core classes in a broader sense than it seems. Older Javadoc > (from version 1.0) used to mention implementation details that were not > necessarily important and limited the applicability of the classes. > Newer documentation tends to go out of its way to avoid mentioning such > implementation detail and I believe that's a good thing. When > InterruptedIOException was written, Thread.interrupt() was probably the > only way to interrupt I/O operations. Nowadays there are others. Sun has > generalized its meaning over time as evident by SocketTimeoutException. > At least, that's my interpretation :) > > Gili > > Kustaa Nyholm wrote: >>> I disagree with your interpretation. Read >>> SocketTimeoutException to >>> see >>> what I mean. InterruptedIOException means the operation was interrupted, >>> not necessarily by way of Thread.interrupt(). >> >> Well SocketTimeoutException javadoc only says, very briefly: >> >> "Signals that a timeout has occurred on a socket read or accept." >> >> So that is not too helpful. But since it is derived from >> InterruptedIOException my interpretation it that they have an 'is-a' >> relationship and InterruptedIOException needs to honor the contract of >> InterruptedIOException which says: >> >> "...because the thread performing it was interrupted." >> >> To me this very specifically talks about interrupting threads with >> Thread.interrupt() >> >> >>> Returning 0 in case of timeout sounds wrong to me because it >>> is a >>> legal >>> byte value that could have been read. >> Agreed, that's what I tried to say. 0 is a legal byte value for read() to >> return so that cannot be used. For read read(byte[]) which returns the >> number of bytes read 0 could be used but there again 0 can be returned >> if 0 >> byte[] size is 0. So there again 0 is not a good option. >> >>> Returning -1 also sounds wrong to >>> me because this isn't strictly the end of stream. >> Like I said, it isn't strictly the end of stream. But also does not >> forbid treating it as (temporary) end of stream. >> >>> BufferedInputStream >>> and others assume that once you reach the end of stream you will never >>> see more data, ever. >> Can you provide a reference for that. >> >>> As far as I know, the core APIs are written in >>> terms of throwing InterruptedIOException for timeouts. >> Would also like to see something to support that. >> >> >> The behavior of throwing an exception on timeout is also a little bit >> problematic, consider: >> >> byte buf[1000]; >> int n=ins.read(buf); >> // do something with the n bytes received >> >> What happens if a timeout occurs before we have received 1000 bytes? >> >> If an exception is thrown then the user of the read() needs to handle >> the bytes received in two places or else those last <1000 bytes are lost. >> A better solution would be to return the bytes received so far and throw >> the exception on the next call (if any). But the main point is that >> neither of these case obviously correct and neither is specified in the >> javadocs. Where as a lot of code that just handles the return value >> of read(byte[]) correctly works without any further ado. >> >> >> >> The main thing is that I think we should not break existing applications, >> which I expect are not handling InterruptedIOException but many of >> which may >> depend on getting back -1 in case of timeouts. >> >> It has been a while since I used the javax.javacomm but I seem to recall >> that it returned -1 and I think this is the defining standard. >> >> I expect most rxtx users are more interested in compatibility and >> stability >> than semantic niceties and improving the API. >> >> br Kusti >> >> >> > From johnny.luong at trustcommerce.com Fri May 15 13:16:15 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Fri, 15 May 2009 12:16:15 -0700 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0DA12D.2050303@bbs.darktech.org> References: <4A0DA0F4.9050203@bbs.darktech.org> <4A0DA12D.2050303@bbs.darktech.org> Message-ID: <4A0DBF7F.50808@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 cowwoc wrote: | Forgot to CC the list. | | Gili | | cowwoc wrote: |> "Thread was interrupted" does not necessarily mean |> Thread.interrupt(). It just means that the operation (run by the thread) |> was interrupted. If you read the beginning sentence for |> InterruptedIOException it reads "Signals that an I/O operation has been |> interrupted". This says nothing about the thread itself. Michael's |> subsequent post about SocketTimeoutException reinforces that point. |> |> By the way, I think that in general you need to interpret the |> Javadoc for core classes in a broader sense than it seems. Older Javadoc |> (from version 1.0) used to mention implementation details that were not |> necessarily important and limited the applicability of the classes. |> Newer documentation tends to go out of its way to avoid mentioning such |> implementation detail and I believe that's a good thing. When |> InterruptedIOException was written, Thread.interrupt() was probably the |> only way to interrupt I/O operations. Nowadays there are others. Sun has |> generalized its meaning over time as evident by SocketTimeoutException. |> At least, that's my interpretation :) |> |> Gili |> |> Kustaa Nyholm wrote: |>>> I disagree with your interpretation. Read |>>> SocketTimeoutException to |>>> see |>>> what I mean. InterruptedIOException means the operation was interrupted, |>>> not necessarily by way of Thread.interrupt(). |>> Well SocketTimeoutException javadoc only says, very briefly: |>> |>> "Signals that a timeout has occurred on a socket read or accept." |>> |>> So that is not too helpful. But since it is derived from |>> InterruptedIOException my interpretation it that they have an 'is-a' |>> relationship and InterruptedIOException needs to honor the contract of |>> InterruptedIOException which says: |>> |>> "...because the thread performing it was interrupted." |>> |>> To me this very specifically talks about interrupting threads with |>> Thread.interrupt() |>> |>> |>>> Returning 0 in case of timeout sounds wrong to me because it |>>> is a |>>> legal |>>> byte value that could have been read. |>> Agreed, that's what I tried to say. 0 is a legal byte value for read() to |>> return so that cannot be used. For read read(byte[]) which returns the |>> number of bytes read 0 could be used but there again 0 can be returned |>> if 0 |>> byte[] size is 0. So there again 0 is not a good option. |>> |>>> Returning -1 also sounds wrong to |>>> me because this isn't strictly the end of stream. |>> Like I said, it isn't strictly the end of stream. But also does not |>> forbid treating it as (temporary) end of stream. |>> |>>> BufferedInputStream |>>> and others assume that once you reach the end of stream you will never |>>> see more data, ever. |>> Can you provide a reference for that. |>> |>>> As far as I know, the core APIs are written in |>>> terms of throwing InterruptedIOException for timeouts. |>> Would also like to see something to support that. |>> |>> |>> The behavior of throwing an exception on timeout is also a little bit |>> problematic, consider: |>> |>> byte buf[1000]; |>> int n=ins.read(buf); |>> // do something with the n bytes received |>> |>> What happens if a timeout occurs before we have received 1000 bytes? |>> |>> If an exception is thrown then the user of the read() needs to handle |>> the bytes received in two places or else those last <1000 bytes are lost. |>> A better solution would be to return the bytes received so far and throw |>> the exception on the next call (if any). But the main point is that |>> neither of these case obviously correct and neither is specified in the |>> javadocs. Where as a lot of code that just handles the return value |>> of read(byte[]) correctly works without any further ado. |>> |>> |>> |>> The main thing is that I think we should not break existing applications, |>> which I expect are not handling InterruptedIOException but many of |>> which may |>> depend on getting back -1 in case of timeouts. |>> |>> It has been a while since I used the javax.javacomm but I seem to recall |>> that it returned -1 and I think this is the defining standard. |>> |>> I expect most rxtx users are more interested in compatibility and |>> stability |>> than semantic niceties and improving the API. |>> |>> br Kusti |>> |>> |>> | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi, Maybe a better approach (improving the API) would be to consider implementing a NIO interface atop the underlying serial communication... ~ if someone desires the existing behavior, then they use a facade that lies atop of the NIO and provide the same quirks associated with it. As I see it, the implementation overrides the general contract of the InputStream to provide for the timeout functionality and it would be somewhat troublesome to expect a user of that API to catch subclasses of IOException. Best, Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoNv38ACgkQnQTBLXttTeWZ+wCeO4CTrI5l+vLPrjHl8fBj7FOL Ft8AnjQ7bXnvMhOlwZdK5CYAuoQeQ9u0 =QAax -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon May 18 03:49:50 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 11:49:50 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <20090518094950.GG17036@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, May 15, 2009 at 17:22 +0300: > >From the javadoc for InputStream: > > Since character timeout is not an indication of EOF condition I > guess one could argue that 0 should be returned in case of > timeout. A blocking operation logically has no timeout. It is blocking. Forever, until EOF or an error. This IMHO renders usage of read() useless and read(byte[]) must be used (or no InputStream). > On the other hand one could also argue that since no data was > available (if it timed out) IMHO, read() must not time out. What would happen with a small simple console app that is relying that InputStream is implemented as required by specification? It cannot tell `no byte was received but this is not an error, please call me again' - and why should it? I think, if this is not suited, i.e. if the application may want a byte but also may not want a byte, no blocking function must be invoked, but a select must be called instead or, if no select-style function is avialable, polling must be used. This is the InputStream way (block or poll). For streams the `may or may not want a byte' may sound unlikely, but in practice this is what happens, for instance, if there is some CANCEL button in a GUI or so. Closing the stream often also is no option because it cannot be reopend but it might be needed again later. In classic unix apps often signals were used (read(2) can return EINTR), but in Java this isn't possible AFAIK. EINTR IMHO has not much relation to InterruptedIOException and I think InterruptedIOException cannot be `enforced' without doing harm. > It goes against my grain to think that I get an exception when > I've set up a timeout yeah, I thought the same and when I hit this InputStream the first time I though: ohh, a bug. Or a bunch of :-) As specified, InputStream has no timeout. If you set a timeout, then somewhere else (e.g. a sub class). In this case, the sub class should also offer a way to wait for this timeout (e.g. a select style function). In practice, this makes not much sense, leaving the options not to use it at all (but what else then?) or to violate the specification. Unfortunately it seems that subclasses add setTimeout but no select() or tryRead() or simply a available()-style with a timeout parameter. Then applications would simply use this subclasses. In practice, then it does not help that they derive InputStream at all, so personally I think they should not derive from it but instead define something with a meaning :-) But I think in practice, for read(byte[]) returning 0 (e.g. in case of [intercharacter] timeout) for many people seems straightforward - so this is probably what most people will expect. (an interesting question is how those bugs happend to the Java guys, because those topics are well known since ages and solved, for instance, in the BSD socket API, but probably they didn't know it. It took years but now it seems they understood and tried it again by some NIO which is more in the `usual way'. Next version might be usable - I wouldn't be surprised if this one then is BSD socket API alike :-) SCNR). So in practice I think: - don't use read() but read(byte[]) or read(byte[], int, int) - handle `0 bytes read' situation - polling avialable() in practice may often not be suited because avialable() has no timeout parameter and if response time is important, small polling intervals would be needed which generate load - try to avoid using InputStream (from applications) directly because it sucks and it is /not/ generic (implementations may interpret it differently because it MUST be interpreted because the specification makes not much sense in many cases) - IOException and InterruptedIOException are for I/O error situations. Additionally I think, InterruptedIOException.bytesTransferred cannot be reliable because there are cases where the OS cannot surely know this and thus cannot tell it the JVM also, peer may have not received them even if they were sent As far as I know this is exactly what rxtx is doing. When having many clients this require many threads and might be less performant, so best is not to have one thousand serial ports :-) Returning 0 here IMHO also is the only option that does not `directly' violate the spec. It tells `there is an attempt to read at least one byte.' so someone could argue that the dear computer `attempted but found no time to do so' :-) > So I'm against changing this behavior. I expect a lot of code > depend on the -1 or at least on not getting an exception when a > timeout occurs. Yes, I agree, -1 means End of file (or closed by peer) and exceptions are for errors. If exceptions should be added I think it could be made configurable. For instance by some Rs232InputStream.enableException(IOException e), store this exception and later if (e != null) throw e.clone() or so. > I do not think this matches the case for serial port receive character > timeout. I read the javadoc above so that I get this exception when the > thread in my code that is performing a read or write operation gets > interrupted by Thread.interrupt(). And this is used to handle exactly that > case: being able to gracefully and cleanly interrupt threads. (well, I think Thread.interrupt() also is a big topic on its own and I'm afraid there is no really reliable mechanism for `cleanly interrupt threads' and maybe even that logically threads cannot be interrupted cleanly at all) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From rxtx at qbang.org Mon May 18 05:17:08 2009 From: rxtx at qbang.org (VIAGRA ® Official Site) Date: Mon, 18 May 2009 05:17:08 -0600 Subject: [Rxtx] DISCOUNT ID42992 75% 0FF on Pfizer ! Message-ID: <200905181117.n4IBH8ku024296@rxtx.qbang.org> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/4c172d08/attachment.html From luis.moreira at ntlworld.com Sat May 2 00:39:04 2009 From: luis.moreira at ntlworld.com (luis.moreira at ntlworld.com) Date: Sat, 2 May 2009 7:39:04 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Hi Travis, The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. The issues I still have is the errors after that. Do you have any idea what can be causing this errors? _______________________________________________________________________________ conftest.c: In function 'main': conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) conftest.c:8: error: (Each undeclared identifier is reported only once conftest.c:8: error: for each function it appears in.) conftest.c:8: error: expected ')' before string constant conftest.c:8: warning: format not a string literal and no format arguments ./configure: line 21462: ./conftest: No such file or directory ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands ------------------------------------------------------------------------------- I don't know what happened to my previous post, it as not showed up in the list. Best Regards Luis From tjarvi at qbang.org Sat May 2 07:30:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 07:30:04 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> References: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Message-ID: On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > Hi Travis, > The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. > The issues I still have is the errors after that. Do you have any idea what can be causing this errors? > > _______________________________________________________________________________ > conftest.c: In function 'main': > conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) > conftest.c:8: error: (Each undeclared identifier is reported only once > conftest.c:8: error: for each function it appears in.) > conftest.c:8: error: expected ')' before string constant > conftest.c:8: warning: format not a string literal and no format arguments > ./configure: line 21462: ./conftest: No such file or directory > ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: config.h is unchanged > config.status: executing depfiles commands > ------------------------------------------------------------------------------- > > This was corrected in CVS. I think you can just do the following in the top directory: cvs login: (pw is mousy) cvs update That will get the current fixes. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sat May 2 16:14:50 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sat, 02 May 2009 23:14:50 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FCC5DA.6000700@ntlworld.com> Trent Jarvi wrote: > > > On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > >> Hi Travis, >> The problem with the Makefile is not a problem,When I run ./configure >> I make a new Makefile with the same data in it, hence what I just >> modified is removed. >> The issues I still have is the errors after that. Do you have any >> idea what can be causing this errors? >> >> _______________________________________________________________________________ >> >> conftest.c: In function 'main': >> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >> function) >> conftest.c:8: error: (Each undeclared identifier is reported only once >> conftest.c:8: error: for each function it appears in.) >> conftest.c:8: error: expected ')' before string constant >> conftest.c:8: warning: format not a string literal and no format >> arguments >> ./configure: line 21462: ./conftest: No such file or directory >> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >> expected >> configure: creating ./config.status >> config.status: creating Makefile >> config.status: creating config.h >> config.status: config.h is unchanged >> config.status: executing depfiles commands >> ------------------------------------------------------------------------------- >> >> >> > > This was corrected in CVS. I think you can just do the following in > the top directory: > > cvs login: (pw is mousy) > cvs update > > That will get the current fixes. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, apologies for the mix-up of your name. I managed to get further on by updating CVS, the configure command gets to the end without any errors, it still warns me that it is confused about where to find the jni_md.h but I just edited the Makefile and sorted that out. I then run make, with no parameters following the instructions on the Wiki, but that generated a few more errors: ----------------------------------------------------------------------------------------------------------------------- gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. -I/usr/lib/jvm/java-6-openjdk/include /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' undeclared (first use in this function) /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared identifier is reported only once /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each function it appears in.) libtool: link: `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 ----------------------------------------------------------------------------------------------------------------------- Another question I have is, in which folder will the .so files be placed after make finishes? thank you very much for your help. Best Regards Luis From tjarvi at qbang.org Sat May 2 19:27:08 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 19:27:08 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FCC5DA.6000700@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> Message-ID: On Sat, 2 May 2009, Luis Moreira wrote: > Trent Jarvi wrote: >> >> >> On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: >> >>> Hi Travis, >>> The problem with the Makefile is not a problem,When I run ./configure >>> I make a new Makefile with the same data in it, hence what I just >>> modified is removed. >>> The issues I still have is the errors after that. Do you have any >>> idea what can be causing this errors? >>> >>> _______________________________________________________________________________ >>> >>> conftest.c: In function 'main': >>> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >>> function) >>> conftest.c:8: error: (Each undeclared identifier is reported only once >>> conftest.c:8: error: for each function it appears in.) >>> conftest.c:8: error: expected ')' before string constant >>> conftest.c:8: warning: format not a string literal and no format >>> arguments >>> ./configure: line 21462: ./conftest: No such file or directory >>> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >>> expected >>> configure: creating ./config.status >>> config.status: creating Makefile >>> config.status: creating config.h >>> config.status: config.h is unchanged >>> config.status: executing depfiles commands >>> ------------------------------------------------------------------------------- >>> >>> >>> >> >> This was corrected in CVS. I think you can just do the following in >> the top directory: >> >> cvs login: (pw is mousy) >> cvs update >> >> That will get the current fixes. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > apologies for the mix-up of your name. > I managed to get further on by updating CVS, the configure command gets > to the end without any errors, it still warns me that it is confused > about where to find the jni_md.h but I just edited the Makefile and > sorted that out. > I then run make, with no parameters following the instructions on the > Wiki, but that generated a few more errors: > ----------------------------------------------------------------------------------------------------------------------- > > gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. > -I/usr/lib/jvm/java-6-openjdk/include > /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE > -D_BSD_SOURCE -D__need_timespec -c > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o > /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' > undeclared (first use in this function) > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared > identifier is reported only once > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each > function it appears in.) > libtool: link: > `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a > valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 > ----------------------------------------------------------------------------------------------------------------------- > > Another question I have is, in which folder will the .so files be placed > after make finishes? > > thank you very much for your help. > Ah when you do cvs update pass the -Pd option cvs update -Pd Also, when you run configure, use --disable-PRINTER to only build the serial support. It will make things easier. --disable-LOCKFILES will also be easier to get going until you want to learn about how to prevent multiple applications from reading the same serial port. The link for debugging will describe where the files go. By default, it will install in the JRE/JDK under jre/lib/ext (the jar file) jre/lib/i386 (the .so file) Those are on the proper paths when you use the sun or ibm jdk. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sun May 3 01:30:43 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sun, 03 May 2009 08:30:43 +0100 Subject: [Rxtx] First use of RXTX package In-Reply-To: References: <49FCC5DA.6000700@ntlworld.com> Message-ID: <49FD4823.5080204@ntlworld.com> Ah > > when you do cvs update pass the -Pd option > > cvs update -Pd > > Also, when you run configure, use --disable-PRINTER to only build the > serial support. It will make things easier. --disable-LOCKFILES will > also be easier to get going until you want to learn about how to > prevent multiple applications from reading the same serial port. > > The link for debugging will describe where the files go. By default, > it will install in the JRE/JDK under > > jre/lib/ext (the jar file) > jre/lib/i386 (the .so file) > > Those are on the proper paths when you use the sun or ibm jdk. > > http://rxtx.qbang.org/wiki/index.php/Trouble_shooting > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, It as done it! I think this instructions you gave me should be on the Wiki, I can write them for you if you like. Also on the Wiki when you describe the three methods of installing the RxTx package it is confusing because as far as I can see, you always have to do method 1 or the .so files will not be generated(is this correct?). Then you can if you like change the location with method 1 & 2. Is it possible to modify the .la file to point to different directories for installation and then you can decide where to place the files? In a way I have learned quite a lot about Linux by having to struggle, with your help, to find solutions to the problems I encountered (I am still very new to Linux), but maybe we need to log these problems somewhere to make it less of a struggle for others like me. I have used the PortLister example to test it and it came up with my USB to dual Serial adaptor Ports. I will now explore the RxTx package, before I tackle the windows installation, I will let you know of my experience. Thank you for all your Help. Best Regards Luis From tjarvi at qbang.org Sun May 3 10:37:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 3 May 2009 10:37:50 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FD4823.5080204@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> <49FD4823.5080204@ntlworld.com> Message-ID: On Sun, 3 May 2009, Luis Moreira wrote: > Ah >> >> when you do cvs update pass the -Pd option >> >> cvs update -Pd >> >> Also, when you run configure, use --disable-PRINTER to only build the >> serial support. It will make things easier. --disable-LOCKFILES will >> also be easier to get going until you want to learn about how to >> prevent multiple applications from reading the same serial port. >> >> The link for debugging will describe where the files go. By default, >> it will install in the JRE/JDK under >> >> jre/lib/ext (the jar file) >> jre/lib/i386 (the .so file) >> >> Those are on the proper paths when you use the sun or ibm jdk. >> >> http://rxtx.qbang.org/wiki/index.php/Trouble_shooting >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > It as done it! > I think this instructions you gave me should be on the Wiki, I can write > them for you if you like. Also on the Wiki when you describe the three > methods of installing the RxTx package it is confusing because as far > as I can see, you always have to do method 1 or the .so files will not > be generated(is this correct?). Then you can if you like change the > location with method 1 & 2. Is it possible to modify the .la file to > point to different directories for installation and then you can decide > where to place the files? > In a way I have learned quite a lot about Linux by having to struggle, > with your help, to find solutions to the problems I encountered (I am > still very new to Linux), but maybe we need to log these problems > somewhere to make it less of a struggle for others like me. > > I have used the PortLister example to test it and it came up with my USB > to dual Serial adaptor Ports. > > I will now explore the RxTx package, before I tackle the windows > installation, I will let you know of my experience. > > Thank you for all your Help. > Hi Luis, The locations suggested for first time configuration could be documented in a new wiki page explaining that this is not the recommended general workflow but does help new users that are not worried about having rxtx installed into the JRE. For a professional environment, the user would want to follow the workflow currently on the wiki and keep their JRE clean. Often the user will not be able to add libraries to the JRE and will need to use their home directory or a sandbox. Feel free to add information to the wiki. I'd suggest creating comment in the current page and have the comment link to what worked for you as a first time user new to Linux. You can create a new page with your comments. In the long term, we will be working on an autoinstaller that works over the web. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Mon May 4 09:15:40 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Mon, 04 May 2009 16:15:40 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FF069C.8040406@ntlworld.com> Hi Trent, I have now installed the package on my 64 bit machine and when I run my program I get errors on the attachment. I know it as something to do with the architecture of my system but I can no figure out how to fix it. I have built it from source again, I did not transfer the files from machine to machine. can you please put me in the right direction. Thank you very much for your help. Best Regards Luis -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshoot.png Type: image/png Size: 25753 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090504/141ab5dc/attachment-0015.png From johnny.luong at trustcommerce.com Mon May 4 11:57:08 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 04 May 2009 10:57:08 -0700 Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FF069C.8040406@ntlworld.com> References: <49FF069C.8040406@ntlworld.com> Message-ID: <49FF2C74.90805@trustcommerce.com> Luis Moreira wrote: > Hi Trent, > I have now installed the package on my 64 bit machine and when I run my > program I get errors on the attachment. I know it as something to do > with the architecture of my system but I can no figure out how to fix > it. I have built it from source again, I did not transfer the files from > machine to machine. > can you please put me in the right direction. > Thank you very much for your help. > Best Regards > Luis > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Hi, Does running it on a 64-bit JVM help? Your host environment might be building objects for a 64-bit environment unless you did a cross-compile... -- you can find out by doing something like the following: johnny at spike:~$ java -version java version "1.6.0_0" OpenJDK Runtime Environment (build 1.6.0_0-b11) OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode) johnny at spike:~$ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) -Johnny From huangdongkai at gmail.com Wed May 6 11:06:06 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 01:06:06 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. Message-ID: Dear all, I recompile the rxtxSerial source code by MinGW32 and compile success. But when I run my Application which use rxtxSerial.dll to communicate with serial port, a runtime exception happened and application crash. I have no idea why it can not work, beacuse i have not change any source code of rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I have missed when compile the source code on Window NT? Here below is the output error massage. # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, tid=1360 # # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing windows-x86) # Problematic frame: # V [jvm.dll+0x1b6824] # # An error report file with more information is saved as: # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/32c1e699/attachment-0013.html From tjarvi at qbang.org Wed May 6 20:04:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 May 2009 20:04:10 -0600 (MDT) Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: On Thu, 7 May 2009, dongkai huang wrote: > Dear all, > ????? I recompile the rxtxSerial source code by MinGW32 and compile success. > But when I run my Application which use rxtxSerial.dll to communicate with > serial port, a runtime exception happened and application crash.? I have no > idea why it can not work, beacuse i have not change any source code of > rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I > have missed when compile the source code on Window NT? Here below is the > output error massage. > # > # An unexpected error has been detected by Java Runtime Environment: > # > #? EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, > tid=1360 > # > # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing > windows-x86) > > # Problematic frame: > # V? [jvm.dll+0x1b6824] > # > # An error report file with more information is saved as: > # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log > # > # If you would like to submit a bug report, please visit: > #?? http://java.sun.com/webapps/bugreport/crash.jsp > # > > > Hi Dongkai Could you explain how you compiled rxtx with mingw? Did you run configure? Was the compiler native or a cross compiler (like compiling on Linux for Windows)? Is the crash happening when you first open the port or is it happening randomly later on? -- Trent Jarvi tjarvi at qbang.org From huangdongkai at gmail.com Wed May 6 20:48:56 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 10:48:56 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Hi Trent, I was followed the step on INSTALL file, did not run the configure, I used the Makefile.mingw32 which include on the source code package, and only change some path( jdk home path etc.). And I use the native compiler on Windows. The crash happened on I call the getPortIdentifiers() every time. On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Dear all, >> I recompile the rxtxSerial source code by MinGW32 and compile >> success. >> But when I run my Application which use rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and application crash. I have >> no >> idea why it can not work, beacuse i have not change any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing >> I >> have missed when compile the source code on Window NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is saved as: >> # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> > Hi Dongkai > > Could you explain how you compiled rxtx with mingw? Did you run configure? > Was the compiler native or a cross compiler (like compiling on Linux for > Windows)? > > Is the crash happening when you first open the port or is it happening > randomly later on? > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/733eded5/attachment-0013.html From m.j.tandy at warwick.ac.uk Thu May 7 10:39:12 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 7 May 2009 17:39:12 +0100 Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. Message-ID: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> I've encountered a bug in how XON/XOFF are handled on Windows. The symptoms were: 1. XON/XOFF from device to PC did not stop transmission. 2. XON/XOFF characters were present in data read from serial port input stream, when it was expected that they would be stripped out. 3. Investigation with SysInternals PortMon revealed the following configuration when using rxtx: 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 while HyperTerminal, which did not have the same problems as me, produced the following: 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 In other words, the problem is that, in addition to being told to use XON/XOFF flow control, the computer has to explicitly be told which characters to use for 'XON' and 'XOFF'. This part of the configuration was being missed out. I got the latest rxtx source from CVS, and identified the problem as an omission in the 'init_termios' function of 'termios.c', which configures the unix/termios 'c_cc' (control characters) data structure - but omits to configure the VSTART and VSTOP control characters. Later, the termios c_cc data structure is translated (by termios_to_DCB) into a data structure named 'DCB', which is passed to the windows serial port configuration interface. By adding two lines defining the standard XON/XOFF characters to the function init_termios, the bug is fixed. A patch doing this is attached. Thanks, Michael Tandy -------------- next part -------------- A non-text attachment was scrubbed... Name: xon-xoff.diff Type: application/octet-stream Size: 667 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/159c0dcc/attachment-0012.obj From tjarvi at qbang.org Thu May 7 17:57:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 May 2009 17:57:28 -0600 (MDT) Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. In-Reply-To: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> References: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> Message-ID: On Thu, 7 May 2009, Michael Tandy wrote: > I've encountered a bug in how XON/XOFF are handled on Windows. > > The symptoms were: > 1. XON/XOFF from device to PC did not stop transmission. > 2. XON/XOFF characters were present in data read from serial port > input stream, when it was expected that they would be stripped out. > 3. Investigation with SysInternals PortMon revealed the following > configuration when using rxtx: > > 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 > BRK:0 EVT:a XON:0 XOFF:0 > > while HyperTerminal, which did not have the same problems as me, > produced the following: > > 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 > > In other words, the problem is that, in addition to being told to use > XON/XOFF flow control, the computer has to explicitly be told which > characters to use for 'XON' and 'XOFF'. This part of the configuration > was being missed out. > > I got the latest rxtx source from CVS, and identified the problem as > an omission in the 'init_termios' function of 'termios.c', which > configures the unix/termios 'c_cc' (control characters) data structure > - but omits to configure the VSTART and VSTOP control characters. > Later, the termios c_cc data structure is translated (by > termios_to_DCB) into a data structure named 'DCB', which is passed to > the windows serial port configuration interface. > > By adding two lines defining the standard XON/XOFF characters to the > function init_termios, the bug is fixed. A patch doing this is > attached. > Thanks Michael, Good timing. I plan on releasing rxtx-2.2 this coming Sunday. -- Trent Jarvi tjarvi at qbang.org From wjr at weru.ksu.edu Fri May 8 11:38:29 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Fri, 08 May 2009 12:38:29 -0500 Subject: [Rxtx] swing jfilechooser lockup Message-ID: <4A046E15.6010907@weru.ksu.edu> Hi, I wrote a small swing app to download images from an industrial camera. I used the two way serial sample code as a starting point. The app works fine EXCEPT for a call to jfilechooser. After I open the comm port and then try to change the output directory or log file, the jfilechooser winds up trying to unpark (note, parking is not something I'm really familiar with) and doesn't. If I try to change the file or directory before I start the comm port, it works. If I click on menu items that don't call jfilechooser, everything is OK. If I try closing the comm port and then try to create a jfilechooser, it locks up. There is obviously some sort of deadlock here because the awt thread starts waiting on something but it's not clear what. I haven't gone thru the rxtx code yet because it's not in the file structure that netbeans wants for debugging purposes. However, debugging code that I don't have a clear idea of what it is supposed to do is not my idea of a good time. Does anyone have any ideas on what is going on here? Thanks, wjr From Bob_Jacobsen at lbl.gov Fri May 8 14:48:25 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Fri, 8 May 2009 13:48:25 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A046E15.6010907@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> Message-ID: At 12:38 PM -0500 5/8/09, Bill Rust wrote: >Hi, > >I wrote a small swing app to download images from an industrial camera. >I used the two way serial sample code as a starting point. The app works >fine EXCEPT for a call to jfilechooser. After I open the comm port and >then try to change the output directory or log file, the jfilechooser >winds up trying to unpark (note, parking is not something I'm really >familiar with) and doesn't. If I try to change the file or directory >before I start the comm port, it works. If I click on menu items that >don't call jfilechooser, everything is OK. If I try closing the comm >port and then try to create a jfilechooser, it locks up. There is >obviously some sort of deadlock here because the awt thread starts >waiting on something but it's not clear what. I haven't gone thru the >rxtx code yet because it's not in the file structure that netbeans wants >for debugging purposes. However, debugging code that I don't have a >clear idea of what it is supposed to do is not my idea of a good time. What is the threading structure of your code? The various high-function Swing components, such as JFileChooser, are notorious for doing Really Bad Stuff when invoked from off the Swing thread. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From bschlining at gmail.com Fri May 8 15:08:50 2009 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 8 May 2009 14:08:50 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: Bob's probably right...take look at javax.swing.SwingUtilites for the workaround to get your swing stuff invoked on the EventDispatchThread (EDT). Some swing-methods do work when called outside of the EDT, but just to be safe, do your creation and swing calls on the EDT. It's really simple, here's an example of a synchronous call. // Here's how to run stuff on the EDT from a different thread SwingUtilities.invokeAndWait(new Runnable() { public void run() { JFileChooser fc; // create, setup, show your filechooser // Get the result from the filechooser } }); To do a asynchronous call use SwingUtilities.invokeLater > >I wrote a small swing app to download images from an industrial camera. > >I used the two way serial sample code as a starting point. The app works > >fine EXCEPT for a call to jfilechooser. After I open the comm port and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090508/c21c2127/attachment-0011.html From tod at todbot.com Fri May 8 16:27:12 2009 From: tod at todbot.com (Tod E. Kurt) Date: Fri, 8 May 2009 15:27:12 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> This is the exact technique I use to let the user choose which serial port to use on startup. Here's a method I've got in many of my sketches: void choosePort() { String portlist[] = Serial.list(); String port = null; javax.swing.SwingUtilities.invokeLater(new Runnable() { public void run() { try { String port = (String) javax.swing.JOptionPane.showInputDialog( null, "Select Serial Port", "MySuperSketch", javax.swing.JOptionPane.QUESTION_MESSAGE, null, portlist, null); if( port == null ) { javax.swing.JOptionPane.showMessageDialog(null, "No port chosen, goodbye"); System.exit(1); } serialPort = port; } catch (Exception e) { e.printStackTrace(); } } } ); } On May 8, 2009, at 2:08 p, Brian Schlining wrote: > Bob's probably right...take look at javax.swing.SwingUtilites for > the workaround to get your swing stuff invoked on the > EventDispatchThread (EDT). Some swing-methods do work when called > outside of the EDT, but just to be safe, do your creation and swing > calls on the EDT. It's really simple, here's an example of a > synchronous call. > > // Here's how to run stuff on the EDT from a different thread > SwingUtilities.invokeAndWait(new Runnable() { > public void run() { > JFileChooser fc; // create, setup, show your filechooser > // Get the result from the filechooser > } > }); > > To do a asynchronous call use SwingUtilities.invokeLater > > > >I wrote a small swing app to download images from an industrial > camera. > >I used the two way serial sample code as a starting point. The app > works > >fine EXCEPT for a call to jfilechooser. After I open the comm port > and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From huangdongkai at gmail.com Sat May 9 04:46:22 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Sat, 9 May 2009 18:46:22 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Dear Trent, After I intsall the ming32-cross compile to compile the rxtxSerial.dll and testing, i found the same problem still exist. I am not sure my compiler version is the same as your's. Could you tell me the way you can success compile rxtx-2.1-7r2 release source code? Thanks for you kindly help. On Fri, May 8, 2009 at 8:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Hi Trent, >> The attach is the Make file I use to compile the rxtx. >> >> On Thu, May 7, 2009 at 10:48 AM, dongkai huang >> wrote: >> Hi Trent, >> I was followed the step on INSTALL file, did not run the >> configure, I used the Makefile.mingw32 which include on the >> source code package, and only change some path( jdk home path >> etc.). And I use the native compiler on Windows. >> The crash happened on I call the getPortIdentifiers() >> every time. >> >> On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: >> >> >> On Thu, 7 May 2009, dongkai huang wrote: >> >> Dear all, >> I recompile the rxtxSerial source code by >> MinGW32 and compile success. >> But when I run my Application which use >> rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and >> application crash. I have no >> idea why it can not work, beacuse i have not change >> any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source >> code. Did some thing I >> have missed when compile the source code on Window >> NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java >> Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at >> pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 >> mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is >> saved as: >> # >> D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please >> visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> >> Hi Dongkai >> >> Could you explain how you compiled rxtx with mingw? Did you run >> configure? Was the compiler native or a cross compiler (like >> compiling on Linux for Windows)? >> >> Is the crash happening when you first open the port or is it >> happening randomly later on? >> >> > Thanks Dongkai > > I'll look at your Makefile tomorrow. Which version of mingw was this? > > I suspect there is a problem with that makefile. I usually built that > version of rxtx for windows with a mingw32 cross compiler using the > configure script. > > The configure script may well work for you if you have a cygwin environment > with mingw instead of gcc. I'll take a look at what is different. > > -- > > Trent Jarvi > tjarvi at qbang.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090509/b729c429/attachment-0011.html From wjr at weru.ksu.edu Wed May 13 15:50:30 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Wed, 13 May 2009 16:50:30 -0500 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> Message-ID: <4A0B40A6.5070204@weru.ksu.edu> Tod's solution misses the point. He is picking and opening the serial port. That's the step before where my problem occurs. To recap: 1. I have a simple java swing app. 2. On the menu bar, there is the standard set, file, etc., of jmenu's. Under file, there is a jmenuitem, logfileopen, which pops up a jfilechooser to select a logfile and another jmenuitem, setprefix, which pops up a jdialog to allow the user to type in a file name prefix for downloaded images. 3. There is another jmenuitem that starts the commport running. 4. When logfileopen is pressed before the commport is started, it works. 5. When logfileopen is pressed after the commport is started, it hangs. 6. setprefix works whether or not the commport is started. 7. portIdentifier.open starts a thread that goes into a native method, RXTXPort.eventLoop, and never returns. 8. java.sun bugs has a bug report, 6741890, that is similar but their workaround doesn't. 9. When it locks up, there is a swing-shell thread that appears to be down in some native libraries, winshellfolder2 10. The awt-eventQ thread is unblocked but in code that says its parked. If you have anymore ideas, I'd really appreciate them. wjr Tod E. Kurt wrote: > This is the exact technique I use to let the user choose which serial > port to use on startup. Here's a method I've got in many of my sketches: > > void choosePort() { > String portlist[] = Serial.list(); > String port = null; > javax.swing.SwingUtilities.invokeLater(new Runnable() { > public void run() { > try { > String port = (String) javax.swing.JOptionPane.showInputDialog( > null, > "Select Serial Port", > "MySuperSketch", > javax.swing.JOptionPane.QUESTION_MESSAGE, > null, portlist, null); > if( port == null ) { > javax.swing.JOptionPane.showMessageDialog(null, "No port > chosen, goodbye"); > System.exit(1); > } > serialPort = port; > } > catch (Exception e) { > e.printStackTrace(); > } > } > } ); > } > > > On May 8, 2009, at 2:08 p, Brian Schlining wrote: > >> Bob's probably right...take look at javax.swing.SwingUtilites for the >> workaround to get your swing stuff invoked on the EventDispatchThread >> (EDT). Some swing-methods do work when called outside of the EDT, but >> just to be safe, do your creation and swing calls on the EDT. It's >> really simple, here's an example of a synchronous call. >> >> // Here's how to run stuff on the EDT from a different thread >> SwingUtilities.invokeAndWait(new Runnable() { >> public void run() { >> JFileChooser fc; // create, setup, show your filechooser >> // Get the result from the filechooser >> } >> }); >> >> To do a asynchronous call use SwingUtilities.invokeLater >> >> >> >I wrote a small swing app to download images from an industrial camera. >> >I used the two way serial sample code as a starting point. The app works >> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >> >then try to change the output directory or log file, the jfilechooser >> >winds up trying to unpark (note, parking is not something I'm really >> >familiar with) and doesn't. >> What is the threading structure of your code? >> >> The various high-function Swing components, such as JFileChooser, are >> notorious for doing Really Bad Stuff when invoked from off the Swing >> thread. >> >> Bob >> -- >> Bob Jacobsen, UC Berkeley >> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >> JacobsenRG >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -- >> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >> Brian Schlining >> bschlining at gmail.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx From m.j.tandy at warwick.ac.uk Wed May 13 16:42:24 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 13 May 2009 23:42:24 +0100 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A0B40A6.5070204@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> <4A0B40A6.5070204@weru.ksu.edu> Message-ID: <302aa0340905131542i601ec3f1w3b0b5879c23f8eca@mail.gmail.com> Perhaps you could post your program, or an excerpt of it sufficient to demonstrate the problem you're having, for us to have a look at? 2009/5/13 Bill Rust : > Tod's solution misses the point. He is picking and opening the serial > port. That's the step before where my problem occurs. > > To recap: > > 1. I have a simple java swing app. > 2. On the menu bar, there is the standard set, file, etc., of jmenu's. > Under file, there is a jmenuitem, logfileopen, which pops up a > jfilechooser to select a logfile and another jmenuitem, setprefix, which > pops up a jdialog to allow the user to type in a file name prefix for > downloaded images. > 3. There is another jmenuitem that starts the commport running. > 4. When logfileopen is pressed before the commport is started, it works. > 5. When logfileopen is pressed after the commport is started, it hangs. > 6. setprefix works whether or not the commport is started. > 7. portIdentifier.open starts a thread that goes into a native > method, ? ? ? ? ? ? ? ? ? ? ? ? RXTXPort.eventLoop, and never returns. > 8. java.sun bugs has a bug report, 6741890, that is similar but > their ? ? ? ? ? ? ? ? ? workaround doesn't. > 9. When it locks up, there is a swing-shell thread that appears to be > ? ? ? ?down in some native libraries, winshellfolder2 > 10. The awt-eventQ thread is unblocked but in code that says its parked. > > If you have anymore ideas, I'd really appreciate them. > > wjr > > Tod E. Kurt wrote: >> This is the exact technique I use to let the user choose which serial >> port to use on startup. ?Here's a method I've got in many of my sketches: >> >> void choosePort() { >> ? String portlist[] = Serial.list(); >> ? String port = null; >> ? javax.swing.SwingUtilities.invokeLater(new Runnable() { >> ? ? public void run() { >> ? ? ? try { >> ? ? ? ? String port = (String) javax.swing.JOptionPane.showInputDialog( >> null, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Select Serial Port", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "MySuperSketch", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? javax.swing.JOptionPane.QUESTION_MESSAGE, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? null, portlist, null); >> ? ? ? ? if( port == null ) ?{ >> ? ? ? ? ? javax.swing.JOptionPane.showMessageDialog(null, "No port >> chosen, goodbye"); >> ? ? ? ? ? System.exit(1); >> ? ? ? ? } >> ? ? ? ? serialPort = port; >> ? ? ? } >> ? ? ? catch (Exception e) { >> ? ? ? ? e.printStackTrace(); >> ? ? ? } >> ? ? } >> ? } ); >> } >> >> >> On May 8, 2009, at 2:08 p, Brian Schlining wrote: >> >>> Bob's probably right...take look at javax.swing.SwingUtilites for the >>> workaround to get your swing stuff invoked on the EventDispatchThread >>> (EDT). Some swing-methods do work when called outside of the EDT, but >>> just to be safe, do your creation and swing calls on the EDT. It's >>> really simple, here's an example of a synchronous call. >>> >>> // Here's how to run stuff on the EDT from a different thread >>> SwingUtilities.invokeAndWait(new Runnable() { >>> ? ? ? public void run() { >>> ? ? ? ? ? ?JFileChooser fc; // create, setup, show your filechooser >>> ? ? ? ? ? ?// Get the result from the filechooser >>> ? ? ? } >>> }); >>> >>> To do a asynchronous call use SwingUtilities.invokeLater >>> >>> >>> >I wrote a small swing app to download images from an industrial camera. >>> >I used the two way serial sample code as a starting point. The app works >>> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >>> >then try to change the output directory or log file, the jfilechooser >>> >winds up trying to unpark (note, parking is not something I'm really >>> >familiar with) and doesn't. >>> What is the threading structure of your code? >>> >>> The various high-function Swing components, such as JFileChooser, are >>> notorious for doing Really Bad Stuff when invoked from off the Swing >>> thread. >>> >>> Bob >>> -- >>> Bob Jacobsen, UC Berkeley >>> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >>> JacobsenRG >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >>> -- >>> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >>> Brian Schlining >>> bschlining at gmail.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From m.j.tandy at warwick.ac.uk Thu May 14 03:05:36 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 14 May 2009 10:05:36 +0100 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A0B40A6.5070204@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> <4A0B40A6.5070204@weru.ksu.edu> Message-ID: <302aa0340905140205p6ceb5a9br24e00a50e9cafa5@mail.gmail.com> Java has a built in deadlock detection utility; run your program from the command line, then (on windows) press Ctrl+Break (On Linux, Ctrl+\ does the trick I'm told). That should produce status information and a stack trace for every running thread, including locks held and locks waited on. Maybe that would contain enough information for you to work out what's locking what? 2009/5/13 Bill Rust : > Tod's solution misses the point. He is picking and opening the serial > port. That's the step before where my problem occurs. > > To recap: > > 1. I have a simple java swing app. > 2. On the menu bar, there is the standard set, file, etc., of jmenu's. > Under file, there is a jmenuitem, logfileopen, which pops up a > jfilechooser to select a logfile and another jmenuitem, setprefix, which > pops up a jdialog to allow the user to type in a file name prefix for > downloaded images. > 3. There is another jmenuitem that starts the commport running. > 4. When logfileopen is pressed before the commport is started, it works. > 5. When logfileopen is pressed after the commport is started, it hangs. > 6. setprefix works whether or not the commport is started. > 7. portIdentifier.open starts a thread that goes into a native > method, ? ? ? ? ? ? ? ? ? ? ? ? RXTXPort.eventLoop, and never returns. > 8. java.sun bugs has a bug report, 6741890, that is similar but > their ? ? ? ? ? ? ? ? ? workaround doesn't. > 9. When it locks up, there is a swing-shell thread that appears to be > ? ? ? ?down in some native libraries, winshellfolder2 > 10. The awt-eventQ thread is unblocked but in code that says its parked. > > If you have anymore ideas, I'd really appreciate them. > > wjr > > Tod E. Kurt wrote: >> This is the exact technique I use to let the user choose which serial >> port to use on startup. ?Here's a method I've got in many of my sketches: >> >> void choosePort() { >> ? String portlist[] = Serial.list(); >> ? String port = null; >> ? javax.swing.SwingUtilities.invokeLater(new Runnable() { >> ? ? public void run() { >> ? ? ? try { >> ? ? ? ? String port = (String) javax.swing.JOptionPane.showInputDialog( >> null, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Select Serial Port", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "MySuperSketch", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? javax.swing.JOptionPane.QUESTION_MESSAGE, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? null, portlist, null); >> ? ? ? ? if( port == null ) ?{ >> ? ? ? ? ? javax.swing.JOptionPane.showMessageDialog(null, "No port >> chosen, goodbye"); >> ? ? ? ? ? System.exit(1); >> ? ? ? ? } >> ? ? ? ? serialPort = port; >> ? ? ? } >> ? ? ? catch (Exception e) { >> ? ? ? ? e.printStackTrace(); >> ? ? ? } >> ? ? } >> ? } ); >> } >> >> >> On May 8, 2009, at 2:08 p, Brian Schlining wrote: >> >>> Bob's probably right...take look at javax.swing.SwingUtilites for the >>> workaround to get your swing stuff invoked on the EventDispatchThread >>> (EDT). Some swing-methods do work when called outside of the EDT, but >>> just to be safe, do your creation and swing calls on the EDT. It's >>> really simple, here's an example of a synchronous call. >>> >>> // Here's how to run stuff on the EDT from a different thread >>> SwingUtilities.invokeAndWait(new Runnable() { >>> ? ? ? public void run() { >>> ? ? ? ? ? ?JFileChooser fc; // create, setup, show your filechooser >>> ? ? ? ? ? ?// Get the result from the filechooser >>> ? ? ? } >>> }); >>> >>> To do a asynchronous call use SwingUtilities.invokeLater >>> >>> >>> >I wrote a small swing app to download images from an industrial camera. >>> >I used the two way serial sample code as a starting point. The app works >>> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >>> >then try to change the output directory or log file, the jfilechooser >>> >winds up trying to unpark (note, parking is not something I'm really >>> >familiar with) and doesn't. >>> What is the threading structure of your code? >>> >>> The various high-function Swing components, such as JFileChooser, are >>> notorious for doing Really Bad Stuff when invoked from off the Swing >>> thread. >>> >>> Bob >>> -- >>> Bob Jacobsen, UC Berkeley >>> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >>> JacobsenRG >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >>> -- >>> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >>> Brian Schlining >>> bschlining at gmail.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From cowwoc at bbs.darktech.org Fri May 15 07:18:29 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 09:18:29 -0400 Subject: [Rxtx] InputStream timeouts Message-ID: <4A0D6BA5.8020209@bbs.darktech.org> Why does InputStream.read() return -1 on timeout instead of throwing InterruptedIOException which has existed specifically for this purpose since JDK 1.0? Sockets throw SocketTimeoutException which extends InterruptedIOException. I suspect that this logic confuses BufferedInputStream as well as end-users. Can we introduce this change along with the other timeout-related changes? Gili From Steffen.DETTMER at ingenico.com Fri May 15 07:36:19 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 15 May 2009 15:36:19 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0D6BA5.8020209@bbs.darktech.org> References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <20090515133619.GC17036@elberon.bln.de.ingenico.com> * cowwoc wrote on Fri, May 15, 2009 at 09:18 -0400: > Why does InputStream.read() return -1 on timeout shouldn't it block and only avialable() should care about timeouts? That is how I understand `This method blocks until input data is available' from: http://java.sun.com/j2se/1.5.0/docs/api/java/io/InputStream.html#read() public abstract int read() throws IOException Reads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. A subclass must provide an implementation of this method. Returns: the next byte of data, or -1 if the end of the stream is reached. Throws: IOException - if an I/O error occurs. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Fri May 15 08:22:19 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 15 May 2009 17:22:19 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: >From the javadoc for InputStream: "If no byte is available because the end of the stream has been reached, the value -1 is returned." Since character timeout is not an indication of EOF condition I guess one could argue that 0 should be returned in case of timeout. On the other hand one could also argue that since no data was available (if it timed out) the serial port input stream was at the end of stream (albeit possibly temporarily only). Further the javadoc seems to forbid the return value 0 for Inputstream.read(): " This method blocks until input data is available, the end of the stream is detected, or an exception is thrown." So it can return n >= 1 , -1 or throw an exception. InputStream.read(byte[]) can return 0 but for consistency the options with the other read methods the return value for timeout needs to be -1 or an exception. It goes against my grain to think that I get an exception when I've set up a timeout and I am thus expecting a timeout to happen sometimes. So it is not an exceptional case but expected situation in which case a special return value is philosophically speaking more appropriate. So I'm against changing this behavior. I expect a lot of code depend on the -1 or at least on not getting an exception when a timeout occurs. In any case if an exception were to be thrown it should *not* be InterruptedIOException. >From the javadoc for InterruptedIOException: "An InterruptedIOException is thrown to indicate that an input or output transfer has been terminated because the thread performing it was interrupted. The field bytesTransferred indicates how many bytes were successfully transferred before the interruption occurred" I do not think this matches the case for serial port receive character timeout. I read the javadoc above so that I get this exception when the thread in my code that is performing a read or write operation gets interrupted by Thread.interrupt(). And this is used to handle exactly that case: being able to gracefully and cleanly interrupt threads. my 2 snt worth br Kusti > From: cowwoc > Date: Fri, 15 May 2009 16:18:29 +0300 > To: rxtx > Conversation: [Rxtx] InputStream timeouts > Subject: [Rxtx] InputStream timeouts > > > > Why does InputStream.read() return -1 on timeout instead of > throwing InterruptedIOException which has existed specifically for this > purpose since JDK 1.0? Sockets throw SocketTimeoutException which > extends InterruptedIOException. I suspect that this logic confuses > BufferedInputStream as well as end-users. Can we introduce this change > along with the other timeout-related changes? > > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From cowwoc at bbs.darktech.org Fri May 15 08:35:27 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 10:35:27 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <4A0D7DAF.5030705@bbs.darktech.org> I disagree with your interpretation. Read SocketTimeoutException to see what I mean. InterruptedIOException means the operation was interrupted, not necessarily by way of Thread.interrupt(). Returning 0 in case of timeout sounds wrong to me because it is a legal byte value that could have been read. Returning -1 also sounds wrong to me because this isn't strictly the end of stream. BufferedInputStream and others assume that once you reach the end of stream you will never see more data, ever. As far as I know, the core APIs are written in terms of throwing InterruptedIOException for timeouts. Gili Kustaa Nyholm wrote: > >>From the javadoc for InputStream: > > "If no byte is available because the end of the stream has been reached, the > value -1 is returned." > > > Since character timeout is not an indication of EOF condition I guess one > could argue that 0 should be returned in case of timeout. On the other hand > one could also argue that since no data was available (if it timed out) the > serial port input stream was at the end of stream (albeit possibly > temporarily only). Further the javadoc seems to forbid the return value 0 > for Inputstream.read(): > > " This method blocks until input data is available, the end of the stream is > detected, or an exception is thrown." > > So it can return n >= 1 , -1 or throw an exception. InputStream.read(byte[]) > can return 0 but for consistency the options with the other read methods the > return value for timeout needs to be -1 or an exception. > > It goes against my grain to think that I get an exception when I've set up a > timeout and I am thus expecting a timeout to happen sometimes. So it is not > an exceptional case but expected situation in which case a special return > value is philosophically speaking more appropriate. > > So I'm against changing this behavior. I expect a lot of code depend on the > -1 or at least on not getting an exception when a timeout occurs. > > In any case if an exception were to be thrown it should *not* be > InterruptedIOException. > >>From the javadoc for InterruptedIOException: > > > "An InterruptedIOException is thrown to indicate that an input or output > transfer has been terminated because the thread performing it was > interrupted. The field bytesTransferred indicates how many bytes were > successfully transferred before the interruption occurred" > > I do not think this matches the case for serial port receive character > timeout. I read the javadoc above so that I get this exception when the > thread in my code that is performing a read or write operation gets > interrupted by Thread.interrupt(). And this is used to handle exactly that > case: being able to gracefully and cleanly interrupt threads. > > > > my 2 snt worth br Kusti > > > > >> From: cowwoc >> Date: Fri, 15 May 2009 16:18:29 +0300 >> To: rxtx >> Conversation: [Rxtx] InputStream timeouts >> Subject: [Rxtx] InputStream timeouts >> >> >> >> Why does InputStream.read() return -1 on timeout instead of >> throwing InterruptedIOException which has existed specifically for this >> purpose since JDK 1.0? Sockets throw SocketTimeoutException which >> extends InterruptedIOException. I suspect that this logic confuses >> BufferedInputStream as well as end-users. Can we introduce this change >> along with the other timeout-related changes? >> >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From m.j.tandy at warwick.ac.uk Fri May 15 09:17:36 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Fri, 15 May 2009 16:17:36 +0100 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <302aa0340905150817o39812d7y1b896004a2dcc2ab@mail.gmail.com> > I disagree with your interpretation. Read SocketTimeoutException to see > what I mean. InterruptedIOException means the operation was interrupted, > not necessarily by way of Thread.interrupt(). Strangely enough, the javadoc for InterruptedIOException says: "An InterruptedIOException is thrown to indicate that an input or output transfer has been terminated because the thread performing it was interrupted."[1] But the subclass SocketTimeoutException is used differently - here's an example from sun.net.httpserver.request: /** * block() only called when available==0 and buf is empty */ private synchronized void block () throws IOException { long currtime = server.getTime(); long maxtime = currtime + readTimeout; while (currtime < maxtime) { if (selector.select (readTimeout) == 1) { selector.selectedKeys().clear(); available (); return; } currtime = server.getTime(); } throw new SocketTimeoutException ("no data received"); } So it seems that SocketTimeoutExceptions get thrown not upon thread interruptions, but a certain time after a blocking read is started. [1] http://java.sun.com/javase/6/docs/api/java/io/InterruptedIOException.html From cowwoc at bbs.darktech.org Fri May 15 11:06:53 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 13:06:53 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0DA0F4.9050203@bbs.darktech.org> References: <4A0DA0F4.9050203@bbs.darktech.org> Message-ID: <4A0DA12D.2050303@bbs.darktech.org> Forgot to CC the list. Gili cowwoc wrote: > > "Thread was interrupted" does not necessarily mean > Thread.interrupt(). It just means that the operation (run by the thread) > was interrupted. If you read the beginning sentence for > InterruptedIOException it reads "Signals that an I/O operation has been > interrupted". This says nothing about the thread itself. Michael's > subsequent post about SocketTimeoutException reinforces that point. > > By the way, I think that in general you need to interpret the > Javadoc for core classes in a broader sense than it seems. Older Javadoc > (from version 1.0) used to mention implementation details that were not > necessarily important and limited the applicability of the classes. > Newer documentation tends to go out of its way to avoid mentioning such > implementation detail and I believe that's a good thing. When > InterruptedIOException was written, Thread.interrupt() was probably the > only way to interrupt I/O operations. Nowadays there are others. Sun has > generalized its meaning over time as evident by SocketTimeoutException. > At least, that's my interpretation :) > > Gili > > Kustaa Nyholm wrote: >>> I disagree with your interpretation. Read >>> SocketTimeoutException to >>> see >>> what I mean. InterruptedIOException means the operation was interrupted, >>> not necessarily by way of Thread.interrupt(). >> >> Well SocketTimeoutException javadoc only says, very briefly: >> >> "Signals that a timeout has occurred on a socket read or accept." >> >> So that is not too helpful. But since it is derived from >> InterruptedIOException my interpretation it that they have an 'is-a' >> relationship and InterruptedIOException needs to honor the contract of >> InterruptedIOException which says: >> >> "...because the thread performing it was interrupted." >> >> To me this very specifically talks about interrupting threads with >> Thread.interrupt() >> >> >>> Returning 0 in case of timeout sounds wrong to me because it >>> is a >>> legal >>> byte value that could have been read. >> Agreed, that's what I tried to say. 0 is a legal byte value for read() to >> return so that cannot be used. For read read(byte[]) which returns the >> number of bytes read 0 could be used but there again 0 can be returned >> if 0 >> byte[] size is 0. So there again 0 is not a good option. >> >>> Returning -1 also sounds wrong to >>> me because this isn't strictly the end of stream. >> Like I said, it isn't strictly the end of stream. But also does not >> forbid treating it as (temporary) end of stream. >> >>> BufferedInputStream >>> and others assume that once you reach the end of stream you will never >>> see more data, ever. >> Can you provide a reference for that. >> >>> As far as I know, the core APIs are written in >>> terms of throwing InterruptedIOException for timeouts. >> Would also like to see something to support that. >> >> >> The behavior of throwing an exception on timeout is also a little bit >> problematic, consider: >> >> byte buf[1000]; >> int n=ins.read(buf); >> // do something with the n bytes received >> >> What happens if a timeout occurs before we have received 1000 bytes? >> >> If an exception is thrown then the user of the read() needs to handle >> the bytes received in two places or else those last <1000 bytes are lost. >> A better solution would be to return the bytes received so far and throw >> the exception on the next call (if any). But the main point is that >> neither of these case obviously correct and neither is specified in the >> javadocs. Where as a lot of code that just handles the return value >> of read(byte[]) correctly works without any further ado. >> >> >> >> The main thing is that I think we should not break existing applications, >> which I expect are not handling InterruptedIOException but many of >> which may >> depend on getting back -1 in case of timeouts. >> >> It has been a while since I used the javax.javacomm but I seem to recall >> that it returned -1 and I think this is the defining standard. >> >> I expect most rxtx users are more interested in compatibility and >> stability >> than semantic niceties and improving the API. >> >> br Kusti >> >> >> > From johnny.luong at trustcommerce.com Fri May 15 13:16:15 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Fri, 15 May 2009 12:16:15 -0700 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0DA12D.2050303@bbs.darktech.org> References: <4A0DA0F4.9050203@bbs.darktech.org> <4A0DA12D.2050303@bbs.darktech.org> Message-ID: <4A0DBF7F.50808@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 cowwoc wrote: | Forgot to CC the list. | | Gili | | cowwoc wrote: |> "Thread was interrupted" does not necessarily mean |> Thread.interrupt(). It just means that the operation (run by the thread) |> was interrupted. If you read the beginning sentence for |> InterruptedIOException it reads "Signals that an I/O operation has been |> interrupted". This says nothing about the thread itself. Michael's |> subsequent post about SocketTimeoutException reinforces that point. |> |> By the way, I think that in general you need to interpret the |> Javadoc for core classes in a broader sense than it seems. Older Javadoc |> (from version 1.0) used to mention implementation details that were not |> necessarily important and limited the applicability of the classes. |> Newer documentation tends to go out of its way to avoid mentioning such |> implementation detail and I believe that's a good thing. When |> InterruptedIOException was written, Thread.interrupt() was probably the |> only way to interrupt I/O operations. Nowadays there are others. Sun has |> generalized its meaning over time as evident by SocketTimeoutException. |> At least, that's my interpretation :) |> |> Gili |> |> Kustaa Nyholm wrote: |>>> I disagree with your interpretation. Read |>>> SocketTimeoutException to |>>> see |>>> what I mean. InterruptedIOException means the operation was interrupted, |>>> not necessarily by way of Thread.interrupt(). |>> Well SocketTimeoutException javadoc only says, very briefly: |>> |>> "Signals that a timeout has occurred on a socket read or accept." |>> |>> So that is not too helpful. But since it is derived from |>> InterruptedIOException my interpretation it that they have an 'is-a' |>> relationship and InterruptedIOException needs to honor the contract of |>> InterruptedIOException which says: |>> |>> "...because the thread performing it was interrupted." |>> |>> To me this very specifically talks about interrupting threads with |>> Thread.interrupt() |>> |>> |>>> Returning 0 in case of timeout sounds wrong to me because it |>>> is a |>>> legal |>>> byte value that could have been read. |>> Agreed, that's what I tried to say. 0 is a legal byte value for read() to |>> return so that cannot be used. For read read(byte[]) which returns the |>> number of bytes read 0 could be used but there again 0 can be returned |>> if 0 |>> byte[] size is 0. So there again 0 is not a good option. |>> |>>> Returning -1 also sounds wrong to |>>> me because this isn't strictly the end of stream. |>> Like I said, it isn't strictly the end of stream. But also does not |>> forbid treating it as (temporary) end of stream. |>> |>>> BufferedInputStream |>>> and others assume that once you reach the end of stream you will never |>>> see more data, ever. |>> Can you provide a reference for that. |>> |>>> As far as I know, the core APIs are written in |>>> terms of throwing InterruptedIOException for timeouts. |>> Would also like to see something to support that. |>> |>> |>> The behavior of throwing an exception on timeout is also a little bit |>> problematic, consider: |>> |>> byte buf[1000]; |>> int n=ins.read(buf); |>> // do something with the n bytes received |>> |>> What happens if a timeout occurs before we have received 1000 bytes? |>> |>> If an exception is thrown then the user of the read() needs to handle |>> the bytes received in two places or else those last <1000 bytes are lost. |>> A better solution would be to return the bytes received so far and throw |>> the exception on the next call (if any). But the main point is that |>> neither of these case obviously correct and neither is specified in the |>> javadocs. Where as a lot of code that just handles the return value |>> of read(byte[]) correctly works without any further ado. |>> |>> |>> |>> The main thing is that I think we should not break existing applications, |>> which I expect are not handling InterruptedIOException but many of |>> which may |>> depend on getting back -1 in case of timeouts. |>> |>> It has been a while since I used the javax.javacomm but I seem to recall |>> that it returned -1 and I think this is the defining standard. |>> |>> I expect most rxtx users are more interested in compatibility and |>> stability |>> than semantic niceties and improving the API. |>> |>> br Kusti |>> |>> |>> | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi, Maybe a better approach (improving the API) would be to consider implementing a NIO interface atop the underlying serial communication... ~ if someone desires the existing behavior, then they use a facade that lies atop of the NIO and provide the same quirks associated with it. As I see it, the implementation overrides the general contract of the InputStream to provide for the timeout functionality and it would be somewhat troublesome to expect a user of that API to catch subclasses of IOException. Best, Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoNv38ACgkQnQTBLXttTeWZ+wCeO4CTrI5l+vLPrjHl8fBj7FOL Ft8AnjQ7bXnvMhOlwZdK5CYAuoQeQ9u0 =QAax -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon May 18 03:49:50 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 11:49:50 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <20090518094950.GG17036@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, May 15, 2009 at 17:22 +0300: > >From the javadoc for InputStream: > > Since character timeout is not an indication of EOF condition I > guess one could argue that 0 should be returned in case of > timeout. A blocking operation logically has no timeout. It is blocking. Forever, until EOF or an error. This IMHO renders usage of read() useless and read(byte[]) must be used (or no InputStream). > On the other hand one could also argue that since no data was > available (if it timed out) IMHO, read() must not time out. What would happen with a small simple console app that is relying that InputStream is implemented as required by specification? It cannot tell `no byte was received but this is not an error, please call me again' - and why should it? I think, if this is not suited, i.e. if the application may want a byte but also may not want a byte, no blocking function must be invoked, but a select must be called instead or, if no select-style function is avialable, polling must be used. This is the InputStream way (block or poll). For streams the `may or may not want a byte' may sound unlikely, but in practice this is what happens, for instance, if there is some CANCEL button in a GUI or so. Closing the stream often also is no option because it cannot be reopend but it might be needed again later. In classic unix apps often signals were used (read(2) can return EINTR), but in Java this isn't possible AFAIK. EINTR IMHO has not much relation to InterruptedIOException and I think InterruptedIOException cannot be `enforced' without doing harm. > It goes against my grain to think that I get an exception when > I've set up a timeout yeah, I thought the same and when I hit this InputStream the first time I though: ohh, a bug. Or a bunch of :-) As specified, InputStream has no timeout. If you set a timeout, then somewhere else (e.g. a sub class). In this case, the sub class should also offer a way to wait for this timeout (e.g. a select style function). In practice, this makes not much sense, leaving the options not to use it at all (but what else then?) or to violate the specification. Unfortunately it seems that subclasses add setTimeout but no select() or tryRead() or simply a available()-style with a timeout parameter. Then applications would simply use this subclasses. In practice, then it does not help that they derive InputStream at all, so personally I think they should not derive from it but instead define something with a meaning :-) But I think in practice, for read(byte[]) returning 0 (e.g. in case of [intercharacter] timeout) for many people seems straightforward - so this is probably what most people will expect. (an interesting question is how those bugs happend to the Java guys, because those topics are well known since ages and solved, for instance, in the BSD socket API, but probably they didn't know it. It took years but now it seems they understood and tried it again by some NIO which is more in the `usual way'. Next version might be usable - I wouldn't be surprised if this one then is BSD socket API alike :-) SCNR). So in practice I think: - don't use read() but read(byte[]) or read(byte[], int, int) - handle `0 bytes read' situation - polling avialable() in practice may often not be suited because avialable() has no timeout parameter and if response time is important, small polling intervals would be needed which generate load - try to avoid using InputStream (from applications) directly because it sucks and it is /not/ generic (implementations may interpret it differently because it MUST be interpreted because the specification makes not much sense in many cases) - IOException and InterruptedIOException are for I/O error situations. Additionally I think, InterruptedIOException.bytesTransferred cannot be reliable because there are cases where the OS cannot surely know this and thus cannot tell it the JVM also, peer may have not received them even if they were sent As far as I know this is exactly what rxtx is doing. When having many clients this require many threads and might be less performant, so best is not to have one thousand serial ports :-) Returning 0 here IMHO also is the only option that does not `directly' violate the spec. It tells `there is an attempt to read at least one byte.' so someone could argue that the dear computer `attempted but found no time to do so' :-) > So I'm against changing this behavior. I expect a lot of code > depend on the -1 or at least on not getting an exception when a > timeout occurs. Yes, I agree, -1 means End of file (or closed by peer) and exceptions are for errors. If exceptions should be added I think it could be made configurable. For instance by some Rs232InputStream.enableException(IOException e), store this exception and later if (e != null) throw e.clone() or so. > I do not think this matches the case for serial port receive character > timeout. I read the javadoc above so that I get this exception when the > thread in my code that is performing a read or write operation gets > interrupted by Thread.interrupt(). And this is used to handle exactly that > case: being able to gracefully and cleanly interrupt threads. (well, I think Thread.interrupt() also is a big topic on its own and I'm afraid there is no really reliable mechanism for `cleanly interrupt threads' and maybe even that logically threads cannot be interrupted cleanly at all) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From rxtx at qbang.org Mon May 18 05:17:08 2009 From: rxtx at qbang.org (VIAGRA ® Official Site) Date: Mon, 18 May 2009 05:17:08 -0600 Subject: [Rxtx] DISCOUNT ID42992 75% 0FF on Pfizer ! Message-ID: <200905181117.n4IBH8ku024296@rxtx.qbang.org> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/4c172d08/attachment-0001.html From Kustaa.Nyholm at planmeca.com Mon May 18 07:20:40 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 18 May 2009 16:20:40 +0300 Subject: [Rxtx] InputStream timeouts Message-ID: Oops, sorry sent this to Steffen directly instead of mailing list. So here for the list: > A blocking operation logically has no timeout. It is blocking. > Forever, until EOF or an error. This IMHO renders usage of read() > useless and read(byte[]) must be used (or no InputStream). This is true, however read(byte[]) too is blocking so logically that (allowing it to return with value 0 in case of timeout) is no better (or worse) than read(). According to InputsStream javadoc only when byte[].length is 0 is read(byte[]) non blocking and can return 0. But to be clear: I'm in favor of returning 0 in case of timeouts for read(byte[]) and -1 for read(). > >> On the other hand one could also argue that since no data was >> available (if it timed out) > > IMHO, read() must not time out. IMHO read() should behave consistently with respect to the other read(...) methods. If we allow them to timeout, we should also allow read() to timeout. And in that case we need a return value that separates that case from normal return value (0-255), so -1 seems like a good candidate. > What would happen with a small > simple console app that is relying that InputStream is > implemented as required by specification? It cannot tell `no byte > was received but this is not an error, please call me again' > - and why should it? I think that the simple console app would be just fine, because timeouts are disabled by default so the simple applications are not affected. > > In practice, this makes not much sense, leaving the options not > to use it at all (but what else then?) or to violate the > specification. The javadoc for CommPort.getInputStream() spells out the rules for timeouts: http://java.sun.com/products/javacomm/reference/api/javax/comm/CommPort.html #getInputStream() So, IMO, while it is interesting to discuss these things the javacomm specs is quite clear about blocking behavior and although there is some conflict between how (file) inputstream behaves and Commport inputstreams behave, I think rxtx should adhere to the javacomm spec. > But I think in practice, for read(byte[]) returning 0 (e.g. in > case of [intercharacter] timeout) for many people > seems straightforward - so this is probably what most people will > expect. Agreed, I'm 100% sure there are lots of people out there that use timeouts and depend on the current behavior. Changing this would not help them but infuriate them. > > (well, I think Thread.interrupt() also is a big topic on its own > and I'm afraid there is no really reliable mechanism for > `cleanly interrupt threads' and maybe even that logically > threads cannot be interrupted cleanly at all) Would be interesting to discuss that too but that is beyond the topic of this thread. However I still believe that the InterruptedIOException was introduced so that blocking IO calls could gracefully 'return' if the calling thread was interrupted. Weather this is reliable or clean or graceful could be discussed but to me it seem reasonable. If you have a thread that is blocking on some I/O we need a mechanism that allows stopping that thread in a controlled manner and InterruptedIOException seems to provide this. cheers Kusti From Steffen.DETTMER at ingenico.com Mon May 18 09:18:37 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 17:18:37 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <20090518151837.GS17036@elberon.bln.de.ingenico.com> [OT] * Kustaa Nyholm wrote on Mon, May 18, 2009 at 16:20 +0300: > > A blocking operation logically has no timeout. It is blocking. > > Forever, until EOF or an error. This IMHO renders usage of read() > > useless and read(byte[]) must be used (or no InputStream). > This is true, however read(byte[]) too is blocking so logically that > (allowing it to return with value 0 in case of timeout) is no better > (or worse) than read(). According to InputsStream javadoc only when > byte[].length is 0 is read(byte[]) non blocking and can return 0. I think the essential difference is that for read(byte[]) returning 0 is somewhat clear, but for read() 0 is a valid byte and thus it would be a horrible mess to also use it for timeouts :) > >> On the other hand one could also argue that since no data was > >> available (if it timed out) > > > > IMHO, read() must not time out. > > IMHO read() should behave consistently with respect to the > other read(...) methods. If we allow them to timeout, we should > also allow read() to timeout. And in that case we need a return > value that separates that case from normal return value (0-255), > so -1 seems like a good candidate. Well, but then this is not consistently to EOF handling... (and if read() cannot be consistent, maybe not using it at all is an option?) > > What would happen with a small simple console app that is > > relying that InputStream is implemented as required by > > specification? It cannot tell `no byte was received but this > > is not an error, please call me again' - and why should it? > I think that the simple console app would be just fine, because > timeouts are disabled by default so the simple applications are > not affected. Not setting timeouts IMHO does not mean no timeouts will be applied but that some default timeout is used instead, which could be infinite or some OS value, which in turn may be configurable (like the TCP wait timeouts). > > In practice, this makes not much sense, leaving the options not > > to use it at all (but what else then?) or to violate the > > specification. > > The javadoc for CommPort.getInputStream() spells out the rules for > timeouts: > > http://java.sun.com/products/javacomm/reference/api/javax/comm/CommPort.html > #getInputStream() > So, IMO, while it is interesting to discuss these things > the javacomm specs is quite clear about blocking behavior > and although there is some conflict between how (file) inputstream > behaves and Commport inputstreams behave, I think rxtx should > adhere to the javacomm spec. I think first this does not clearly state what happens a read caller when a timeout occures and second IMHO it does violate the InputStream specification contract (API/javadoc). Formally speaking, it is a bug :-) Also those `advisory methods' in a formal interface are bad, I think. But another topic and discussed already several times :) Yes, in the end it seems the clear correct possiblity (no timeouts) makes no sense, so something pragmatic is needed :-) > > But I think in practice, for read(byte[]) returning 0 (e.g. in > > case of [intercharacter] timeout) for many people > > seems straightforward - so this is probably what most people will > > expect. > Agreed, I'm 100% sure there are lots of people out there that > use timeouts and depend on the current behavior. Changing this > would not help them but infuriate them. yeah, and when shifting to another type of InputStream suddenly they may break, rendering that interface a bit useless, but this is all we have... Correct IMHO would be that the compiler is able to check whether an interface supports timeouts or not (i.e. all methods exist and work as specified or a different interface must be used. Lets say we would have InputStream and InputStreamTimeout or whatever, there would be so many possibilities, but most with own disadvantages). Well, I wonder why they did not even add a timeout parameter to available() and why they forgot about write timeouts completely (also there is no counterpart to available()). Anyway. > > (well, I think Thread.interrupt() also is a big topic on its own > > and I'm afraid there is no really reliable mechanism for > > `cleanly interrupt threads' and maybe even that logically > > threads cannot be interrupted cleanly at all) > Would be interesting to discuss that too but that is beyond the > topic of this thread. However I still believe that the > InterruptedIOException was introduced so that blocking > IO calls could gracefully 'return' if the calling thread > was interrupted. Yes, maybe they forgot it in first place, then found that read can throw IOExceptions only and thus invented InterruptedIOException for InterruptedException-alike cases? but anyway. > Weather this is reliable or clean or graceful could be > discussed but to me it seem reasonable. (With not reliable I mean, when for instance you wanted to write 10 byte and you get this exception telling 5 byte have been written, you cannot be sure what this means. Maybe the 6th byte is in a fifo or whatever. I think best is to avoid the need to handle this). > If you have a thread that is blocking on some I/O we need a > mechanism that allows stopping that thread in a controlled > manner and InterruptedIOException seems to provide this. I think also this is not reliable, because even if the JVM knows a thread is supposed to be `killed', I see at least two issues: first is that native code may be active and cannot be forced to return and second it could be that the thread would need to perform clean up tasks, and since Java does not support RAII (destructors cannot clean), at least you get in trouble when exceptions happening during this cleanup (i.e. exceptions after the thread stops). This in turn IMHO is likely to happen because a well-known situation to interrupt such a thread might be after some error, and after errors exceptions I think happen more often (because less well tested and others). Let's say the thread uses an InputStream (owned by someone else) and now discards it by calling it's close (which should be a delete - because what is an input stream which is closed? Obviously it is not an input stream anymore :-)). Now you might have a special InputStream requiring special things (it might be a protocol requiring some final quit message to be sent, it might need not to close it if used by someone else, too, additional actions may be needed). Logically this could be implemented (turing complete language :-)), but in practice it might not be possible, simply because too complex (to do it right in all circumstances). oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Mon May 18 10:02:39 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 18 May 2009 19:02:39 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: > Not setting timeouts IMHO does not mean no timeouts will be > applied but that some default timeout is used instead, which > could be infinite or some OS value, which in turn may be > configurable (like the TCP wait timeouts). > The javadoc says: "By default, receive timeout is not enabled." and "By default, receive threshold is not enabled." thus (from getInputStream javadoc): "block until any data is available" which is consistent InputStream contract. > I think first this does not clearly state what happens a read > caller when a timeout occures That is true. > and second IMHO it does violate the > InputStream specification contract (API/javadoc). Formally > speaking, it is a bug :-) Agreed, but I think given the advantages you get by using InputStream (as means of reading the serial port as opposed to coming up with some totally new Stream concept) I think this was reasonable compromise and bending of the rules. > yeah, and when shifting to another type of InputStream suddenly > they may break, rendering that interface a bit useless, but this > is all we have... Exactly. > (With not reliable I mean, when for instance you wanted to write > 10 byte and you get this exception telling 5 byte have been > written, you cannot be sure what this means. Maybe the 6th byte > is in a fifo or whatever. I think best is to avoid the need to > handle this). I think all we can assume is that at least 5 bytes have been written into the native driver, weather they are in the fifo or whatever we cannot know. But as you wrote, best avoid depending on this behaviour. > I think also this is not reliable, because even if the JVM knows > a thread is supposed to be `killed', I see at least two issues: > first is that native code may be active and cannot be forced to > return Yes, but this is sort of implementation detail, not an API or Java design issue. The JVM and system class implementations should guarantee this (I bet they don't, consistently, for all platforms and OSes). > and second it could be that the thread would need to > perform clean up tasks, and since Java does not support RAII > (destructors cannot clean), at least you get in trouble when > exceptions happening during this cleanup (i.e. exceptions after > the thread stops). I sort of see what you mean, but still I do not see how this could happen if the cleanup catches exceptions properly. But then I've not studied this in detail. > This in turn IMHO is likely to happen because > a well-known situation to interrupt such a thread might be after > some error, and after errors exceptions I think happen more often > (because less well tested and others). > > Let's say the thread uses an InputStream (owned by someone else) > and now discards it by calling it's close (which should be a > delete - because what is an input stream which is closed? > Obviously it is not an input stream anymore :-)). > Now you might have a special InputStream requiring special things > (it might be a protocol requiring some final quit message to be > sent, it might need not to close it if used by someone else, > too, additional actions may be needed). > Logically this could be implemented (turing complete language :-)), > but in practice it might not be possible, simply because too > complex (to do it right in all circumstances). Ok, I think I understand what you mean: you are saying that what mention aboce "if the cleanup catches exceptions properly" maybe be and often is too difficult/complex to implement and test properly? Yeah, seen that, been there, fallen for it... cheers Kusti From Steffen.DETTMER at ingenico.com Mon May 18 10:39:26 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 18:39:26 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: <20090518163925.GV17036@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Mon, May 18, 2009 at 19:02 +0300: > > Not setting timeouts IMHO does not mean no timeouts will be > > applied but that some default timeout is used instead, which > > could be infinite or some OS value, which in turn may be > > configurable (like the TCP wait timeouts). > > > The javadoc says: > "By default, receive timeout is not enabled." > and > "By default, receive threshold is not enabled." mmm... but they are optional, so what if a driver does not support timeouts but underlaying comm interface does? anyway, *I* would not rely (but loop) but maybe this is not needed. > > and second IMHO it does violate the > > InputStream specification contract (API/javadoc). Formally > > speaking, it is a bug :-) > Agreed, but I think given the advantages you get by using > InputStream (as means of reading the serial port as opposed > to coming up with some totally new Stream concept) I think > this was reasonable compromise and bending of the rules. I don't like InputStream at all. I think it is not an abstraction to remove and later re-add (hack in) needing things. I dislike that noone knows whether it streams bytes or chars or unicode or whatever. Also, I'm used birectional things (`all things are files') for communications, I think it is simpler. So InputStream IMHO is oversimplified. Maybe it was inspired by unix line discipline (but you can select it :-)). Who knows. Anyway. > > I think also this is not reliable, because even if the JVM knows > > a thread is supposed to be `killed', I see at least two issues: > > first is that native code may be active and cannot be forced to > > return > Yes, but this is sort of implementation detail, not an API or > Java design issue. The JVM and system class implementations should > guarantee this (I bet they don't, consistently, for all platforms > and OSes). I think when no reasonable implementation is possible, probably the design is not good. If there is no reasonable way to shutdown (kill) a thread (which is the case IMHO), it makes not much sense to design it. Instead, some mechanism would be needed. I guess the InterruptedException in fact is such a kind of mechanism. I'm not sure but I think Java itself disencourages to use it. > > and second it could be that the thread would need to > > perform clean up tasks, and since Java does not support RAII > > (destructors cannot clean), at least you get in trouble when > > exceptions happening during this cleanup (i.e. exceptions after > > the thread stops). > I sort of see what you mean, but still I do not see how this > could happen if the cleanup catches exceptions properly. But > then I've not studied this in detail. > Ok, I think I understand what you mean: you are saying that > what mention aboce "if the cleanup catches exceptions properly" > maybe be and often is too difficult/complex to implement and > test properly? Yes, since it should work for any implementation, it should work for InputStreams that call abitrary complex read operations. I have applications where the read leads to some CORBA calls to a remote C++ application which also has its complexity. Now in some finally {} exceptions can occure, for instance during member destruction (closing). For example, if you have a facade like implementation with: { old = setMyLogLevel(off); for (i=0; i Yeah, seen that, been there, fallen for it... (welcome in the club :-)) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bill7007 at gmail.com Mon May 18 11:08:45 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 18 May 2009 13:08:45 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090518151837.GS17036@elberon.bln.de.ingenico.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: I can add this thought, I think the timeout is part of a protocol, which should sit above RXTX. The main feature needed in RXTX to support a protocol using timeouts is a way to interrupt it into a known state, like a reset() function. The function should cause an exception to any associated thread that was waiting on IO, maybe a unique exception due to reset() call. An IO (as opposed to Interrupted) exception may be better since the reset() has to leave a known state which may affect IO in progress. I helped work a similar situation in a CAN bus protocol. In the protocol, a send would be followed by a wait for receive. A timeout thread was enabled which caused an "alarm" event to any registered handlers upon timeout. A receive canceled the timeout alarm. The timing and thread coordination is tricky but that is all left to the protocol code. The protocols timeout event handler reset the CAN controller to get it into a known state for a retry. The reset caused an IO exception to the waiting read thread which could check that a timeout had caused it. So, if timeout is considered part of a higher level protocol class, read and write don't need special interface features as long as there is a way for a waiting state in native code to be forced to exit in a reliable, detectable, manner. +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/c9b25045/attachment.html From johnny.luong at trustcommerce.com Mon May 18 11:49:53 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 18 May 2009 10:49:53 -0700 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: <4A119FC1.3090700@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Johnson wrote: | I can add this thought, I think the timeout is part of a protocol, which | should sit above RXTX. The main feature needed in RXTX to support a protocol | using timeouts is a way to interrupt it into a known state, like a reset() | function. The function should cause an exception to any associated thread | that was waiting on IO, maybe a unique exception due to reset() call. An IO | (as opposed to Interrupted) exception may be better since the reset() has to | leave a known state which may affect IO in progress. | | I helped work a similar situation in a CAN bus protocol. In the protocol, a | send would be followed by a wait for receive. A timeout thread was enabled | which caused an "alarm" event to any registered handlers upon timeout. A | receive canceled the timeout alarm. The timing and thread coordination is | tricky but that is all left to the protocol code. The protocols timeout | event handler reset the CAN controller to get it into a known state for a | retry. The reset caused an IO exception to the waiting read thread which | could check that a timeout had caused it. | | So, if timeout is considered part of a higher level protocol class, read and | write don't need special interface features as long as there is a way for a | waiting state in native code to be forced to exit in a reliable, detectable, | manner. | | +BillJ | | | | ------------------------------------------------------------------------ | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx Hi Bill, This is all conjecture and probably a lot of work in practice, so its just a train of thought at this point (via NIO)... Supposer SerialPort were to implement a method that returned "SerialPortChannel" which worked along similar lines as a SocketChannel. ~ Then you could in practice, have a Selector object that did the timeout you described above (via a register method)... your read and write methods could block or not block and it would be a lot easier to drive multiple serial ports than what you have today. - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoRn8EACgkQnQTBLXttTeXm0gCfaua0ej3Rt0fogRR68bbEFG0Z BTwAn1s79U8ZU0yj6xcND8gyHzDmKKqq =ThWj -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon May 18 11:54:10 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 19:54:10 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: <20090518175409.GW17036@elberon.bln.de.ingenico.com> (OT) * Bill Johnson wrote on Mon, May 18, 2009 at 13:08 -0400: > I can add this thought, I think the timeout is part of a > protocol, which should sit above RXTX. Probably actually on both levels timeouts can be helpful; if there is some PPP/TCP or other full duplex multiplexing protcol I think at least it is nice to be able to read with some reasonable timeout(s). > I helped work a similar situation in a CAN bus protocol. In the > protocol, a send would be followed by a wait for receive. A > timeout thread was enabled which caused an "alarm" event to > any registered handlers upon timeout. A receive canceled the > timeout alarm. The timing and thread coordination is tricky but > that is all left to the protocol code. (this Bosch car protocol?) But if the protocol implementation knows the timeout value, wouldn't it be easier and suited better to have some way to apply it to the reads without needing multithreading? Was the implementation in Java? How to cancel the receive by the timeout alarm? Was it (protocol thread implementation) internally polling? You said later, `a way for a waiting state in native code to be forced to exit in a reliable, detectable, manner'. Sounds complicated :) Is this a generic requirement? I think, protocols often can be implemented to use InputStream (or some other interface) but also to offer the same interface (like the decorator pattern). At least when `stacking' such protocols it can become quite difficult, even if having an own thread per protocol instance. Of course heavily depends on the project and situation. Well, interesting topic :) > The protocols timeout event handler reset the CAN controller to > get it into a known state for a retry. The reset caused an IO > exception to the waiting read thread which could check that a > timeout had caused it. Ohh, the CAN controller must be reset? Though they would handle a whole frame automatically. I have no clue about this; surely it is very specific and complex. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bill7007 at gmail.com Mon May 18 12:25:19 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 18 May 2009 14:25:19 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A119FC1.3090700@trustcommerce.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <4A119FC1.3090700@trustcommerce.com> Message-ID: Hi Johnny, I think a SerialPortChannel could be a good example. It uses an underlying Socket which uses an underlying implementation to support open, timeouts, etc. As part of the implementation is where the current RXTX could come in, provided there is a way to back out of a blocking situation. +BillJ On Mon, May 18, 2009 at 1:49 PM, Johnny Luong < johnny.luong at trustcommerce.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Bill Johnson wrote: > | I can add this thought, I think the timeout is part of a protocol, which > | should sit above RXTX. > ... > > Hi Bill, > > This is all conjecture and probably a lot of work in practice, so its > just a train of thought at this point (via NIO)... > > Supposer SerialPort were to implement a method that returned > "SerialPortChannel" which worked along similar lines as a SocketChannel. > ~ Then you could in practice, have a Selector object that did the timeout > you described above (via a register method)... your read and write > methods could block or not block and it would be a lot easier to drive > multiple serial ports than what you have today. > > - -Johnny > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkoRn8EACgkQnQTBLXttTeXm0gCfaua0ej3Rt0fogRR68bbEFG0Z > BTwAn1s79U8ZU0yj6xcND8gyHzDmKKqq > =ThWj > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/0a44a920/attachment.html From lyon at docjava.com Mon May 18 13:18:53 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 18 May 2009 15:18:53 -0400 Subject: [Rxtx] image capture In-Reply-To: References: Message-ID: Hi All, I know this is off-topic, but we have so many native method interface experts here, I just had to ask; Is anyone able to do image capture on a 64 bit mac, using Java? QT4J is not loadable using Java 6 (AFAIK). Thanks! - Doug From bill7007 at gmail.com Mon May 18 13:24:04 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 18 May 2009 15:24:04 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090518175409.GW17036@elberon.bln.de.ingenico.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> Message-ID: On Mon, May 18, 2009 at 1:54 PM, Steffen DETTMER < Steffen.DETTMER at ingenico.com> wrote: > (OT) > > * Bill Johnson wrote on Mon, May 18, 2009 at 13:08 -0400: > > I can add this thought, I think the timeout is part of a > > protocol, which should sit above RXTX. > > Probably actually on both levels timeouts can be helpful; if > there is some PPP/TCP or other full duplex multiplexing protcol I > think at least it is nice to be able to read with some reasonable > timeout(s). I think timeout at the native level does not fit well with a read() concept of timeout because it depends on the protocol not really on the read(). > > > I helped work a similar situation in a CAN bus protocol. In the > > protocol, a send would be followed by a wait for receive. A > > timeout thread was enabled which caused an "alarm" event to > > any registered handlers upon timeout. A receive canceled the > > timeout alarm. The timing and thread coordination is tricky but > > that is all left to the protocol code. > > (this Bosch car protocol?) > > But if the protocol implementation knows the timeout value, > wouldn't it be easier and suited better to have some way to apply > it to the reads without needing multithreading? > If you are waiting on a read and you are waiting on a timeout at the same time, that is two logical threads. Maybe you are looping check for one of two condition, character or timeout, but I think its the same logically as waiting for a character or a timeout exception. It is a special case where you try to read except if it take too long, sound a little like code? > Was the implementation in Java? How to cancel the receive by the > timeout alarm? Was it (protocol thread implementation) internally > polling? > The CAN bus was Java on a TINI embedded system for a warehouse system. It implemented a guaranteed delivery data path patterned after the Datagram interface, I called it a Cangram :-) The problem was how to cancel a read as part of a detected protocol or controller error. The hardware was reset via the native code driver which released resources so a restart was successful. I may have garbaged a thread and started a new one as part of it. > > You said later, `a way for a waiting state in native code to > be forced to exit in a reliable, detectable, manner'. Sounds > complicated :) Is this a generic requirement? I think, protocols > often can be implemented to use InputStream (or some other > interface) but also to offer the same interface (like the > decorator pattern). At least when `stacking' such protocols it > can become quite difficult, even if having an own thread per > protocol instance. Of course heavily depends on the project and > situation. Well, interesting topic :) > I think it (reset, stop, interrupt, whatever) should be a general requirement for any Java native interface code. Without it, your application can lock up and there is no reasonable way to regain control. > > The protocols timeout event handler reset the CAN controller to > > get it into a known state for a retry. The reset caused an IO > > exception to the waiting read thread which could check that a > > timeout had caused it. > > Ohh, the CAN controller must be reset? Though they would handle a > whole frame automatically. > I have no clue about this; surely it is very specific and complex. > The native interface resets it. In most cases, the only reason to reset it was so the native interface was freed up for a retry. If they had a interrupt() function, that may have been better. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. > This message may contain confidential and/or privileged information. If > you are not the addressee or authorized to receive this for the addressee, > you must not use, copy, disclose or take any action based on this message or > any information herein. If you have received this message in error, please > advise the sender immediately by reply e-mail and delete this message. Thank > you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/7df09a1e/attachment-0001.html From beat.arnet at gmail.com Mon May 18 13:27:07 2009 From: beat.arnet at gmail.com (Beat Arnet) Date: Mon, 18 May 2009 15:27:07 -0400 Subject: [Rxtx] Error 0x3e3 at termios.c(1301) Message-ID: All, I am experiencing a situation in which RXTX crashes consistently (both with 2.1 and 2.2). Steps to reproduce: - computer with JAVA program is sending bytes over RS-232 to embedded device, embedded device is off - embedded device powers up and transmit startup banner - JVM crashes: Error 0x3e3 at termios.c(1301) Any idea of what I should be looking for? Thanks! Beat # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6163696c, pid=808, tid=9648 # # Java VM: Java HotSpot(TM) Client VM (1.6.0-b105 mixed mode) # Problematic frame: # C 0x6163696c # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x0af7e400): JavaThread "Thread-4" [_thread_in_native, id=9648] siginfo: ExceptionCode=0xc0000005, reading address 0x6163696c Registers: EAX=0xffffffff, EBX=0x78652064, ECX=0x7c90f661, EDX=0x00000005 ESP=0x0c68f990, EBP=0x70706120, ESI=0x6f207469, EDI=0x6e612072 EIP=0x6163696c, EFLAGS=0x00010206 Top of Stack: (sp=0x0c68f990) 0x0c68f990: 6e6f6974 71657220 74736575 0a0a0d2e 0x0c68f9a0: 00000000 0c68f9d4 6d94556c 0daa3cb4 0x0c68f9b0: 74697277 74794265 3e0d2065 0a000a3e 0x0c68f9c0: 7c90cfea 7c80a059 000007d4 0af7e400 0x0c68f9d0: 6d909d8d 000007d4 00000002 6d945bf6 0x0c68f9e0: 0af7e400 00000001 00000000 0af8b024 0x0c68f9f0: 00000032 0af8b038 00000002 00000000 0x0c68fa00: 00000000 0af7e400 0af8b02c 06e85900 Instructions: (pc=0x6163696c) 0x6163695c: [error occurred during error reporting, step 100, id 0xc0000005] Stack: [0x0c640000,0x0c690000), sp=0x0c68f990, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C 0x6163696c [error occurred during error reporting, step 120, id 0xc0000005] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeByte(IZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write(I)V+86 j codeskin.serial.SerialPortRxtx2_1.write(I)V+29 j codeskin.c2oooprog.BootLoader2xxx$PingTask.run()V+87 v ~StubRoutines::call_stub -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/a692f306/attachment.html From cowwoc at bbs.darktech.org Mon May 18 15:43:15 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Mon, 18 May 2009 17:43:15 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <4A119FC1.3090700@trustcommerce.com> Message-ID: <4A11D673.7080508@bbs.darktech.org> I'm in favor of using SerialPortChannel for timeouts and InputStream for non-blocking reads. This will allow us to follow the specification to the letter without any funky side-effects. In my view breaking the InputStream specification is a far greater sin than throwing InterruptedIOException from read(). Using SerialPortChannel and InputStream should allow us to please people in both camps without breaking the specification. Gili Bill Johnson wrote: > Hi Johnny, > > I think a SerialPortChannel could be a good example. It uses an > underlying Socket which uses an underlying implementation to support > open, timeouts, etc. As part of the implementation is where the current > RXTX could come in, provided there is a way to back out of a blocking > situation. > > +BillJ > > On Mon, May 18, 2009 at 1:49 PM, Johnny Luong > > > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Bill Johnson wrote: > | I can add this thought, I think the timeout is part of a protocol, > which > | should sit above RXTX. > > ... > > > Hi Bill, > > This is all conjecture and probably a lot of work in practice, so its > just a train of thought at this point (via NIO)... > > Supposer SerialPort were to implement a method that returned > "SerialPortChannel" which worked along similar lines as a SocketChannel. > ~ Then you could in practice, have a Selector object that did the > timeout > you described above (via a register method)... your read and write > methods could block or not block and it would be a lot easier to drive > multiple serial ports than what you have today. > > - -Johnny > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkoRn8EACgkQnQTBLXttTeXm0gCfaua0ej3Rt0fogRR68bbEFG0Z > BTwAn1s79U8ZU0yj6xcND8gyHzDmKKqq > =ThWj > -----END PGP SIGNATURE----- > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From bschlining at gmail.com Mon May 18 21:20:25 2009 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 18 May 2009 20:20:25 -0700 Subject: [Rxtx] Fwd: image capture In-Reply-To: References: Message-ID: forgot to cc the list ---------- Forwarded message ---------- From: Brian Schlining Date: Mon, May 18, 2009 at 20:19 Subject: Re: [Rxtx] image capture To: "Dr. Douglas Lyon" > Is anyone able to do image capture on a 64 bit mac, using > Java? Yes, I'm doing it from both video capture cards (Kona and Blackmagic) as well as from movie files. I'm only doing it on Java 5 (Mac) though. > QT4J is not loadable using Java 6 (AFAIK). Are you running this on a Mac or PC? Not that it matters I guess. QT4J is (unofficially) dead. It will be officially deprecated when Mac OS X 10.6 (Snow Leopard) is released, but for all practical purposes it's passed away. With each new release of QuickTime in the past year, I do the mad scramble to work around all the changes and bugs that are introduced. I'm working on once such 'fix' right now as a matter of fact. It's too bad too, QT4J was pretty darn powerful. Your best bet going forward is to rip out the QT4J code and replace it with a Mac/PC/Linux abstraction layer. On a Mac there you could try rococoa ( https://rococoa.dev.java.net) or just grab some QTKit samples off of Apples' developer site and write a JNI or JNA interface. On a PC, not sure what to tell you. I don't know what Apple's plans are with QT4J on a PC. They are pushing everyone away from QuickTime (C API) to QTKit (Cocoa/Objective-C). But on a PC ASFAIK there is no QTKit, so it's still QuickTime in the key of C. -- B ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/913800a4/attachment.html From Kustaa.Nyholm at planmeca.com Tue May 19 00:26:27 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 19 May 2009 09:26:27 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A11D673.7080508@bbs.darktech.org> Message-ID: Oops, did it again, did not send this to the list, so we go: > > I'm in favor of using SerialPortChannel for timeouts and InputStream > for non-blocking reads. This will allow us to follow the specification > to the letter without any funky side-effects. > It was not clear to me what Gili is advocating here so I felt I needed to clarify this. > > In my view breaking the InputStream specification is a far greater sin > than throwing InterruptedIOException from read(). Throwing InterruptedIOException from InputStream.read() is just as big sin as it breaks the contract of InterruptedIOException , which says that the *thread* that was performing the IO was interrupted. Coneceptually I feel throwing an exception is a big sin in a situation which is not an error. A time out in a serial communication is almost always to be excepted since it is used to deal with real, live hardware outside the computer and very often it is a part of the higher level communication protocol, for example used to package or frame messages. Exceptions should be reserved for exceptional things not used for something that the programmer expects to happen normally. For one thing they incur an overhead. Granted, in a typical 9600 baud ie 1ms/char case the overhead is negligible, but it is there. On my 2.8 GHz Core 2 Duo try/throw/catch takes about 13 usec. In my view it is simply wrong to throw an exception for timeouts in a serial port. An even greater sin would be breaking existing code for design purity, at least in this case. > Using > SerialPortChannel and InputStream should allow us to please people in > both camps without breaking the specification. > So you are advocating adding a new class SerialPortChannel and a new method SerialPort.getSerialPortChannel() ? That would be acceptable in that it would not brake existing code but totally unnecessary in my view. I suspect most people turn to rxtx as a replacement for javacomm and are only interested in getting the job done. And the current API does this with very nicely. I think we all have better use for our time than to re-invent a serial port API. If the API bothers someone, I suggest they write a wrapper to implement the improvements and release it for interested users, if any. Would be kind of fun to see them struggle with all the API design issues and see what intellectual compromises they have to concede to. As a famous film ends in the sentence: "Nobody's perfect." cheers Kusti From Steffen.DETTMER at ingenico.com Tue May 19 02:12:14 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 19 May 2009 10:12:14 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A11D673.7080508@bbs.darktech.org> Message-ID: <20090519081214.GY17036@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Tue, May 19, 2009 at 09:26 +0300: > Coneceptually I feel throwing an exception is a big sin in a situation > which is not an error. Yes, I think the same. > In my view it is simply wrong to throw an exception for timeouts in > a serial port. Yes, I agree! > An even greater sin would be breaking existing code for design > purity, at least in this case. An even greater sin than that IMHO would be if the new stuff still isn't undoubtful powerful (which would IMHO need to include the possibility to select serial, TCP and other files simultaneously on systems that support it, e.g. for multi-serial-console applications or so). > So you are advocating adding a new class SerialPortChannel and > a new method SerialPort.getSerialPortChannel() ? SerialPortChannel would be a java.nio.channels.SelectableChannel or so? Or maybe a AbstractGatheringInterruptibleSelectableReadableWritableByteChannel. (the java name for `int fd' lol - SCNR). If changeing, I think an option could be to implement straightforward in native code offering its natural API (full timeout support, maybe as mandatory parameter, not dealing with Channel, Streams, source&sink, reactor&proactor patterns :-)). On top of that then both Channel and Stream and maybe something else for someone else. > That would be acceptable in that it would not brake existing code but > totally unnecessary in my view. I suspect most people turn to rxtx > as a replacement for javacomm and are only interested in getting the > job done. Yes, and most probably just have a few simultaneous connections. Others may need to have a dedicated, specialized and highly optimized JNI impl anyway (I guess). > If the API bothers someone, I suggest they write a wrapper to > implement the improvements and release it for interested users, > if any. Yes, actually that was what we did, but sometimes it was a bit cumbersome (because of InputStream and stuff). We implemented on top of that (instead of native interfaces or such) assuming that those interfaces won't change (but JNI interfaces probably are considered implementation details and thus probably will change). > Would be kind of fun to see them struggle with all the API > design issues and see what intellectual compromises they have > to concede to. Yeah, and then a nio successor comes and everone wanna go with it then :-) oki, Steffen ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Tue May 19 02:33:35 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 19 May 2009 10:33:35 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> Message-ID: <20090519083335.GZ17036@elberon.bln.de.ingenico.com> Hi! * Bill Johnson wrote on Mon, May 18, 2009 at 15:24 -0400: > * On Mon, May 18, 2009 at 1:54 PM, Steffen DETTMER wrote: > > * Bill Johnson wrote on Mon, May 18, 2009 at 13:08 -0400: > > > I can add this thought, I think the timeout is part of a > > > protocol, which should sit above RXTX. > > > > Probably actually on both levels timeouts can be helpful; if > > there is some PPP/TCP or other full duplex multiplexing > > protcol I think at least it is nice to be able to read with > > some reasonable timeout(s). > > I think timeout at the native level does not fit well with a > read() concept of timeout because it depends on the protocol > not really on the read(). What is special about `native level' to gain a special handling? I think all levels should support timeouts. Of course the read timeout an application invokes on a TCP stream has no direct relation to a PPP timeout and intercharacter timeouts on serial lines often depend on serial speed, CPU speed, required response timings, interrupt load etc, I think. So yes, I agree that protocols (often) define needed timeouts (to the lower layer) and the lower layer must offer support for timeouts. Is this what you mean with `depends on the protocol'? > > (this Bosch car protocol?) > > > > But if the protocol implementation knows the timeout value, > > wouldn't it be easier and suited better to have some way to apply > > it to the reads without needing multithreading? > > If you are waiting on a read and you are waiting on a timeout at the same > time, that is two logical threads. Ohh no, I disagree. I think, only if you have plenty of resources it is possible to waste a whole thread to watch a clock. When you have to read 100 connections of course you can use 100 threads, but better would be 1 thread with a select (or epoll or whatever), especially when assuming that the timeout is just a wait (thread sleep) time (when the OS is buffering the data anyway, which on Java running OSes probably is common). > Maybe you are looping check for one of two condition, character > or timeout, but I think its the same logically as waiting for a > character or a timeout exception. It is a special case where > you try to read except if it take too long, sound a little like > code? But isn't a maximum time a natural property of waiting? When you wait for someone for a meeting or so, you look to your watch from time to time and after half an hour or so you leave or continue your business. Select style IMHO is logically more event based than multi-threaded synchronous, but for applications or protocol implementations I found it comfortable when timeouts can be configured at any time. We even have two optional timeout parameters on our read function which eases implementing requirements like `receive both characters within 200 ms or reply with X'. > The CAN bus was Java on a TINI embedded system for a warehouse > system. It implemented a guaranteed delivery data path > patterned after the Datagram interface, I called it a Cangram > :-) The problem was how to cancel a read as part of a detected > protocol or controller error. The hardware was reset via the > native code driver which released resources so a restart was > successful. I may have garbaged a thread and started a new one > as part of it. cool :-) guess this was a very interesting project :) > I think it (reset, stop, interrupt, whatever) should be a > general requirement for any Java native interface code. Without > it, your application can lock up and there is no reasonable way > to regain control. alternatively, it could be required that any JNI function must return after some latest amount of time (i.e. specifying the maximum invocation time). I think, third-path-interruptions, maybe triggered from different threads, could quickly make code complicated because suddenly so many possible code paths can happen and they are hard to test (and cover). Personally, I think this is a major point against avoidable thread usage (even more if threads are not orthogonal) - hard to test, hard to ensure and prove it really is wrong always. Of course often enough it is needed anyway... oki, Steffen ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From luis.moreira at ntlworld.com Sat May 2 00:39:04 2009 From: luis.moreira at ntlworld.com (luis.moreira at ntlworld.com) Date: Sat, 2 May 2009 7:39:04 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Hi Travis, The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. The issues I still have is the errors after that. Do you have any idea what can be causing this errors? _______________________________________________________________________________ conftest.c: In function 'main': conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) conftest.c:8: error: (Each undeclared identifier is reported only once conftest.c:8: error: for each function it appears in.) conftest.c:8: error: expected ')' before string constant conftest.c:8: warning: format not a string literal and no format arguments ./configure: line 21462: ./conftest: No such file or directory ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands ------------------------------------------------------------------------------- I don't know what happened to my previous post, it as not showed up in the list. Best Regards Luis From tjarvi at qbang.org Sat May 2 07:30:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 07:30:04 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> References: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Message-ID: On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > Hi Travis, > The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. > The issues I still have is the errors after that. Do you have any idea what can be causing this errors? > > _______________________________________________________________________________ > conftest.c: In function 'main': > conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) > conftest.c:8: error: (Each undeclared identifier is reported only once > conftest.c:8: error: for each function it appears in.) > conftest.c:8: error: expected ')' before string constant > conftest.c:8: warning: format not a string literal and no format arguments > ./configure: line 21462: ./conftest: No such file or directory > ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: config.h is unchanged > config.status: executing depfiles commands > ------------------------------------------------------------------------------- > > This was corrected in CVS. I think you can just do the following in the top directory: cvs login: (pw is mousy) cvs update That will get the current fixes. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sat May 2 16:14:50 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sat, 02 May 2009 23:14:50 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FCC5DA.6000700@ntlworld.com> Trent Jarvi wrote: > > > On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > >> Hi Travis, >> The problem with the Makefile is not a problem,When I run ./configure >> I make a new Makefile with the same data in it, hence what I just >> modified is removed. >> The issues I still have is the errors after that. Do you have any >> idea what can be causing this errors? >> >> _______________________________________________________________________________ >> >> conftest.c: In function 'main': >> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >> function) >> conftest.c:8: error: (Each undeclared identifier is reported only once >> conftest.c:8: error: for each function it appears in.) >> conftest.c:8: error: expected ')' before string constant >> conftest.c:8: warning: format not a string literal and no format >> arguments >> ./configure: line 21462: ./conftest: No such file or directory >> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >> expected >> configure: creating ./config.status >> config.status: creating Makefile >> config.status: creating config.h >> config.status: config.h is unchanged >> config.status: executing depfiles commands >> ------------------------------------------------------------------------------- >> >> >> > > This was corrected in CVS. I think you can just do the following in > the top directory: > > cvs login: (pw is mousy) > cvs update > > That will get the current fixes. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, apologies for the mix-up of your name. I managed to get further on by updating CVS, the configure command gets to the end without any errors, it still warns me that it is confused about where to find the jni_md.h but I just edited the Makefile and sorted that out. I then run make, with no parameters following the instructions on the Wiki, but that generated a few more errors: ----------------------------------------------------------------------------------------------------------------------- gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. -I/usr/lib/jvm/java-6-openjdk/include /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' undeclared (first use in this function) /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared identifier is reported only once /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each function it appears in.) libtool: link: `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 ----------------------------------------------------------------------------------------------------------------------- Another question I have is, in which folder will the .so files be placed after make finishes? thank you very much for your help. Best Regards Luis From tjarvi at qbang.org Sat May 2 19:27:08 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 19:27:08 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FCC5DA.6000700@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> Message-ID: On Sat, 2 May 2009, Luis Moreira wrote: > Trent Jarvi wrote: >> >> >> On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: >> >>> Hi Travis, >>> The problem with the Makefile is not a problem,When I run ./configure >>> I make a new Makefile with the same data in it, hence what I just >>> modified is removed. >>> The issues I still have is the errors after that. Do you have any >>> idea what can be causing this errors? >>> >>> _______________________________________________________________________________ >>> >>> conftest.c: In function 'main': >>> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >>> function) >>> conftest.c:8: error: (Each undeclared identifier is reported only once >>> conftest.c:8: error: for each function it appears in.) >>> conftest.c:8: error: expected ')' before string constant >>> conftest.c:8: warning: format not a string literal and no format >>> arguments >>> ./configure: line 21462: ./conftest: No such file or directory >>> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >>> expected >>> configure: creating ./config.status >>> config.status: creating Makefile >>> config.status: creating config.h >>> config.status: config.h is unchanged >>> config.status: executing depfiles commands >>> ------------------------------------------------------------------------------- >>> >>> >>> >> >> This was corrected in CVS. I think you can just do the following in >> the top directory: >> >> cvs login: (pw is mousy) >> cvs update >> >> That will get the current fixes. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > apologies for the mix-up of your name. > I managed to get further on by updating CVS, the configure command gets > to the end without any errors, it still warns me that it is confused > about where to find the jni_md.h but I just edited the Makefile and > sorted that out. > I then run make, with no parameters following the instructions on the > Wiki, but that generated a few more errors: > ----------------------------------------------------------------------------------------------------------------------- > > gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. > -I/usr/lib/jvm/java-6-openjdk/include > /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE > -D_BSD_SOURCE -D__need_timespec -c > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o > /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' > undeclared (first use in this function) > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared > identifier is reported only once > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each > function it appears in.) > libtool: link: > `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a > valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 > ----------------------------------------------------------------------------------------------------------------------- > > Another question I have is, in which folder will the .so files be placed > after make finishes? > > thank you very much for your help. > Ah when you do cvs update pass the -Pd option cvs update -Pd Also, when you run configure, use --disable-PRINTER to only build the serial support. It will make things easier. --disable-LOCKFILES will also be easier to get going until you want to learn about how to prevent multiple applications from reading the same serial port. The link for debugging will describe where the files go. By default, it will install in the JRE/JDK under jre/lib/ext (the jar file) jre/lib/i386 (the .so file) Those are on the proper paths when you use the sun or ibm jdk. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sun May 3 01:30:43 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sun, 03 May 2009 08:30:43 +0100 Subject: [Rxtx] First use of RXTX package In-Reply-To: References: <49FCC5DA.6000700@ntlworld.com> Message-ID: <49FD4823.5080204@ntlworld.com> Ah > > when you do cvs update pass the -Pd option > > cvs update -Pd > > Also, when you run configure, use --disable-PRINTER to only build the > serial support. It will make things easier. --disable-LOCKFILES will > also be easier to get going until you want to learn about how to > prevent multiple applications from reading the same serial port. > > The link for debugging will describe where the files go. By default, > it will install in the JRE/JDK under > > jre/lib/ext (the jar file) > jre/lib/i386 (the .so file) > > Those are on the proper paths when you use the sun or ibm jdk. > > http://rxtx.qbang.org/wiki/index.php/Trouble_shooting > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, It as done it! I think this instructions you gave me should be on the Wiki, I can write them for you if you like. Also on the Wiki when you describe the three methods of installing the RxTx package it is confusing because as far as I can see, you always have to do method 1 or the .so files will not be generated(is this correct?). Then you can if you like change the location with method 1 & 2. Is it possible to modify the .la file to point to different directories for installation and then you can decide where to place the files? In a way I have learned quite a lot about Linux by having to struggle, with your help, to find solutions to the problems I encountered (I am still very new to Linux), but maybe we need to log these problems somewhere to make it less of a struggle for others like me. I have used the PortLister example to test it and it came up with my USB to dual Serial adaptor Ports. I will now explore the RxTx package, before I tackle the windows installation, I will let you know of my experience. Thank you for all your Help. Best Regards Luis From tjarvi at qbang.org Sun May 3 10:37:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 3 May 2009 10:37:50 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FD4823.5080204@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> <49FD4823.5080204@ntlworld.com> Message-ID: On Sun, 3 May 2009, Luis Moreira wrote: > Ah >> >> when you do cvs update pass the -Pd option >> >> cvs update -Pd >> >> Also, when you run configure, use --disable-PRINTER to only build the >> serial support. It will make things easier. --disable-LOCKFILES will >> also be easier to get going until you want to learn about how to >> prevent multiple applications from reading the same serial port. >> >> The link for debugging will describe where the files go. By default, >> it will install in the JRE/JDK under >> >> jre/lib/ext (the jar file) >> jre/lib/i386 (the .so file) >> >> Those are on the proper paths when you use the sun or ibm jdk. >> >> http://rxtx.qbang.org/wiki/index.php/Trouble_shooting >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > It as done it! > I think this instructions you gave me should be on the Wiki, I can write > them for you if you like. Also on the Wiki when you describe the three > methods of installing the RxTx package it is confusing because as far > as I can see, you always have to do method 1 or the .so files will not > be generated(is this correct?). Then you can if you like change the > location with method 1 & 2. Is it possible to modify the .la file to > point to different directories for installation and then you can decide > where to place the files? > In a way I have learned quite a lot about Linux by having to struggle, > with your help, to find solutions to the problems I encountered (I am > still very new to Linux), but maybe we need to log these problems > somewhere to make it less of a struggle for others like me. > > I have used the PortLister example to test it and it came up with my USB > to dual Serial adaptor Ports. > > I will now explore the RxTx package, before I tackle the windows > installation, I will let you know of my experience. > > Thank you for all your Help. > Hi Luis, The locations suggested for first time configuration could be documented in a new wiki page explaining that this is not the recommended general workflow but does help new users that are not worried about having rxtx installed into the JRE. For a professional environment, the user would want to follow the workflow currently on the wiki and keep their JRE clean. Often the user will not be able to add libraries to the JRE and will need to use their home directory or a sandbox. Feel free to add information to the wiki. I'd suggest creating comment in the current page and have the comment link to what worked for you as a first time user new to Linux. You can create a new page with your comments. In the long term, we will be working on an autoinstaller that works over the web. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Mon May 4 09:15:40 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Mon, 04 May 2009 16:15:40 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FF069C.8040406@ntlworld.com> Hi Trent, I have now installed the package on my 64 bit machine and when I run my program I get errors on the attachment. I know it as something to do with the architecture of my system but I can no figure out how to fix it. I have built it from source again, I did not transfer the files from machine to machine. can you please put me in the right direction. Thank you very much for your help. Best Regards Luis -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshoot.png Type: image/png Size: 25753 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090504/141ab5dc/attachment-0016.png From johnny.luong at trustcommerce.com Mon May 4 11:57:08 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 04 May 2009 10:57:08 -0700 Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FF069C.8040406@ntlworld.com> References: <49FF069C.8040406@ntlworld.com> Message-ID: <49FF2C74.90805@trustcommerce.com> Luis Moreira wrote: > Hi Trent, > I have now installed the package on my 64 bit machine and when I run my > program I get errors on the attachment. I know it as something to do > with the architecture of my system but I can no figure out how to fix > it. I have built it from source again, I did not transfer the files from > machine to machine. > can you please put me in the right direction. > Thank you very much for your help. > Best Regards > Luis > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Hi, Does running it on a 64-bit JVM help? Your host environment might be building objects for a 64-bit environment unless you did a cross-compile... -- you can find out by doing something like the following: johnny at spike:~$ java -version java version "1.6.0_0" OpenJDK Runtime Environment (build 1.6.0_0-b11) OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode) johnny at spike:~$ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) -Johnny From huangdongkai at gmail.com Wed May 6 11:06:06 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 01:06:06 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. Message-ID: Dear all, I recompile the rxtxSerial source code by MinGW32 and compile success. But when I run my Application which use rxtxSerial.dll to communicate with serial port, a runtime exception happened and application crash. I have no idea why it can not work, beacuse i have not change any source code of rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I have missed when compile the source code on Window NT? Here below is the output error massage. # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, tid=1360 # # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing windows-x86) # Problematic frame: # V [jvm.dll+0x1b6824] # # An error report file with more information is saved as: # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/32c1e699/attachment-0014.html From tjarvi at qbang.org Wed May 6 20:04:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 May 2009 20:04:10 -0600 (MDT) Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: On Thu, 7 May 2009, dongkai huang wrote: > Dear all, > ????? I recompile the rxtxSerial source code by MinGW32 and compile success. > But when I run my Application which use rxtxSerial.dll to communicate with > serial port, a runtime exception happened and application crash.? I have no > idea why it can not work, beacuse i have not change any source code of > rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I > have missed when compile the source code on Window NT? Here below is the > output error massage. > # > # An unexpected error has been detected by Java Runtime Environment: > # > #? EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, > tid=1360 > # > # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing > windows-x86) > > # Problematic frame: > # V? [jvm.dll+0x1b6824] > # > # An error report file with more information is saved as: > # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log > # > # If you would like to submit a bug report, please visit: > #?? http://java.sun.com/webapps/bugreport/crash.jsp > # > > > Hi Dongkai Could you explain how you compiled rxtx with mingw? Did you run configure? Was the compiler native or a cross compiler (like compiling on Linux for Windows)? Is the crash happening when you first open the port or is it happening randomly later on? -- Trent Jarvi tjarvi at qbang.org From huangdongkai at gmail.com Wed May 6 20:48:56 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 10:48:56 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Hi Trent, I was followed the step on INSTALL file, did not run the configure, I used the Makefile.mingw32 which include on the source code package, and only change some path( jdk home path etc.). And I use the native compiler on Windows. The crash happened on I call the getPortIdentifiers() every time. On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Dear all, >> I recompile the rxtxSerial source code by MinGW32 and compile >> success. >> But when I run my Application which use rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and application crash. I have >> no >> idea why it can not work, beacuse i have not change any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing >> I >> have missed when compile the source code on Window NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is saved as: >> # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> > Hi Dongkai > > Could you explain how you compiled rxtx with mingw? Did you run configure? > Was the compiler native or a cross compiler (like compiling on Linux for > Windows)? > > Is the crash happening when you first open the port or is it happening > randomly later on? > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/733eded5/attachment-0014.html From m.j.tandy at warwick.ac.uk Thu May 7 10:39:12 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 7 May 2009 17:39:12 +0100 Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. Message-ID: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> I've encountered a bug in how XON/XOFF are handled on Windows. The symptoms were: 1. XON/XOFF from device to PC did not stop transmission. 2. XON/XOFF characters were present in data read from serial port input stream, when it was expected that they would be stripped out. 3. Investigation with SysInternals PortMon revealed the following configuration when using rxtx: 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 while HyperTerminal, which did not have the same problems as me, produced the following: 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 In other words, the problem is that, in addition to being told to use XON/XOFF flow control, the computer has to explicitly be told which characters to use for 'XON' and 'XOFF'. This part of the configuration was being missed out. I got the latest rxtx source from CVS, and identified the problem as an omission in the 'init_termios' function of 'termios.c', which configures the unix/termios 'c_cc' (control characters) data structure - but omits to configure the VSTART and VSTOP control characters. Later, the termios c_cc data structure is translated (by termios_to_DCB) into a data structure named 'DCB', which is passed to the windows serial port configuration interface. By adding two lines defining the standard XON/XOFF characters to the function init_termios, the bug is fixed. A patch doing this is attached. Thanks, Michael Tandy -------------- next part -------------- A non-text attachment was scrubbed... Name: xon-xoff.diff Type: application/octet-stream Size: 667 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/159c0dcc/attachment-0013.obj From tjarvi at qbang.org Thu May 7 17:57:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 May 2009 17:57:28 -0600 (MDT) Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. In-Reply-To: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> References: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> Message-ID: On Thu, 7 May 2009, Michael Tandy wrote: > I've encountered a bug in how XON/XOFF are handled on Windows. > > The symptoms were: > 1. XON/XOFF from device to PC did not stop transmission. > 2. XON/XOFF characters were present in data read from serial port > input stream, when it was expected that they would be stripped out. > 3. Investigation with SysInternals PortMon revealed the following > configuration when using rxtx: > > 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 > BRK:0 EVT:a XON:0 XOFF:0 > > while HyperTerminal, which did not have the same problems as me, > produced the following: > > 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 > > In other words, the problem is that, in addition to being told to use > XON/XOFF flow control, the computer has to explicitly be told which > characters to use for 'XON' and 'XOFF'. This part of the configuration > was being missed out. > > I got the latest rxtx source from CVS, and identified the problem as > an omission in the 'init_termios' function of 'termios.c', which > configures the unix/termios 'c_cc' (control characters) data structure > - but omits to configure the VSTART and VSTOP control characters. > Later, the termios c_cc data structure is translated (by > termios_to_DCB) into a data structure named 'DCB', which is passed to > the windows serial port configuration interface. > > By adding two lines defining the standard XON/XOFF characters to the > function init_termios, the bug is fixed. A patch doing this is > attached. > Thanks Michael, Good timing. I plan on releasing rxtx-2.2 this coming Sunday. -- Trent Jarvi tjarvi at qbang.org From wjr at weru.ksu.edu Fri May 8 11:38:29 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Fri, 08 May 2009 12:38:29 -0500 Subject: [Rxtx] swing jfilechooser lockup Message-ID: <4A046E15.6010907@weru.ksu.edu> Hi, I wrote a small swing app to download images from an industrial camera. I used the two way serial sample code as a starting point. The app works fine EXCEPT for a call to jfilechooser. After I open the comm port and then try to change the output directory or log file, the jfilechooser winds up trying to unpark (note, parking is not something I'm really familiar with) and doesn't. If I try to change the file or directory before I start the comm port, it works. If I click on menu items that don't call jfilechooser, everything is OK. If I try closing the comm port and then try to create a jfilechooser, it locks up. There is obviously some sort of deadlock here because the awt thread starts waiting on something but it's not clear what. I haven't gone thru the rxtx code yet because it's not in the file structure that netbeans wants for debugging purposes. However, debugging code that I don't have a clear idea of what it is supposed to do is not my idea of a good time. Does anyone have any ideas on what is going on here? Thanks, wjr From Bob_Jacobsen at lbl.gov Fri May 8 14:48:25 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Fri, 8 May 2009 13:48:25 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A046E15.6010907@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> Message-ID: At 12:38 PM -0500 5/8/09, Bill Rust wrote: >Hi, > >I wrote a small swing app to download images from an industrial camera. >I used the two way serial sample code as a starting point. The app works >fine EXCEPT for a call to jfilechooser. After I open the comm port and >then try to change the output directory or log file, the jfilechooser >winds up trying to unpark (note, parking is not something I'm really >familiar with) and doesn't. If I try to change the file or directory >before I start the comm port, it works. If I click on menu items that >don't call jfilechooser, everything is OK. If I try closing the comm >port and then try to create a jfilechooser, it locks up. There is >obviously some sort of deadlock here because the awt thread starts >waiting on something but it's not clear what. I haven't gone thru the >rxtx code yet because it's not in the file structure that netbeans wants >for debugging purposes. However, debugging code that I don't have a >clear idea of what it is supposed to do is not my idea of a good time. What is the threading structure of your code? The various high-function Swing components, such as JFileChooser, are notorious for doing Really Bad Stuff when invoked from off the Swing thread. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From bschlining at gmail.com Fri May 8 15:08:50 2009 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 8 May 2009 14:08:50 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: Bob's probably right...take look at javax.swing.SwingUtilites for the workaround to get your swing stuff invoked on the EventDispatchThread (EDT). Some swing-methods do work when called outside of the EDT, but just to be safe, do your creation and swing calls on the EDT. It's really simple, here's an example of a synchronous call. // Here's how to run stuff on the EDT from a different thread SwingUtilities.invokeAndWait(new Runnable() { public void run() { JFileChooser fc; // create, setup, show your filechooser // Get the result from the filechooser } }); To do a asynchronous call use SwingUtilities.invokeLater > >I wrote a small swing app to download images from an industrial camera. > >I used the two way serial sample code as a starting point. The app works > >fine EXCEPT for a call to jfilechooser. After I open the comm port and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090508/c21c2127/attachment-0012.html From tod at todbot.com Fri May 8 16:27:12 2009 From: tod at todbot.com (Tod E. Kurt) Date: Fri, 8 May 2009 15:27:12 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> This is the exact technique I use to let the user choose which serial port to use on startup. Here's a method I've got in many of my sketches: void choosePort() { String portlist[] = Serial.list(); String port = null; javax.swing.SwingUtilities.invokeLater(new Runnable() { public void run() { try { String port = (String) javax.swing.JOptionPane.showInputDialog( null, "Select Serial Port", "MySuperSketch", javax.swing.JOptionPane.QUESTION_MESSAGE, null, portlist, null); if( port == null ) { javax.swing.JOptionPane.showMessageDialog(null, "No port chosen, goodbye"); System.exit(1); } serialPort = port; } catch (Exception e) { e.printStackTrace(); } } } ); } On May 8, 2009, at 2:08 p, Brian Schlining wrote: > Bob's probably right...take look at javax.swing.SwingUtilites for > the workaround to get your swing stuff invoked on the > EventDispatchThread (EDT). Some swing-methods do work when called > outside of the EDT, but just to be safe, do your creation and swing > calls on the EDT. It's really simple, here's an example of a > synchronous call. > > // Here's how to run stuff on the EDT from a different thread > SwingUtilities.invokeAndWait(new Runnable() { > public void run() { > JFileChooser fc; // create, setup, show your filechooser > // Get the result from the filechooser > } > }); > > To do a asynchronous call use SwingUtilities.invokeLater > > > >I wrote a small swing app to download images from an industrial > camera. > >I used the two way serial sample code as a starting point. The app > works > >fine EXCEPT for a call to jfilechooser. After I open the comm port > and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From huangdongkai at gmail.com Sat May 9 04:46:22 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Sat, 9 May 2009 18:46:22 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Dear Trent, After I intsall the ming32-cross compile to compile the rxtxSerial.dll and testing, i found the same problem still exist. I am not sure my compiler version is the same as your's. Could you tell me the way you can success compile rxtx-2.1-7r2 release source code? Thanks for you kindly help. On Fri, May 8, 2009 at 8:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Hi Trent, >> The attach is the Make file I use to compile the rxtx. >> >> On Thu, May 7, 2009 at 10:48 AM, dongkai huang >> wrote: >> Hi Trent, >> I was followed the step on INSTALL file, did not run the >> configure, I used the Makefile.mingw32 which include on the >> source code package, and only change some path( jdk home path >> etc.). And I use the native compiler on Windows. >> The crash happened on I call the getPortIdentifiers() >> every time. >> >> On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: >> >> >> On Thu, 7 May 2009, dongkai huang wrote: >> >> Dear all, >> I recompile the rxtxSerial source code by >> MinGW32 and compile success. >> But when I run my Application which use >> rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and >> application crash. I have no >> idea why it can not work, beacuse i have not change >> any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source >> code. Did some thing I >> have missed when compile the source code on Window >> NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java >> Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at >> pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 >> mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is >> saved as: >> # >> D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please >> visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> >> Hi Dongkai >> >> Could you explain how you compiled rxtx with mingw? Did you run >> configure? Was the compiler native or a cross compiler (like >> compiling on Linux for Windows)? >> >> Is the crash happening when you first open the port or is it >> happening randomly later on? >> >> > Thanks Dongkai > > I'll look at your Makefile tomorrow. Which version of mingw was this? > > I suspect there is a problem with that makefile. I usually built that > version of rxtx for windows with a mingw32 cross compiler using the > configure script. > > The configure script may well work for you if you have a cygwin environment > with mingw instead of gcc. I'll take a look at what is different. > > -- > > Trent Jarvi > tjarvi at qbang.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090509/b729c429/attachment-0012.html From wjr at weru.ksu.edu Wed May 13 15:50:30 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Wed, 13 May 2009 16:50:30 -0500 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> Message-ID: <4A0B40A6.5070204@weru.ksu.edu> Tod's solution misses the point. He is picking and opening the serial port. That's the step before where my problem occurs. To recap: 1. I have a simple java swing app. 2. On the menu bar, there is the standard set, file, etc., of jmenu's. Under file, there is a jmenuitem, logfileopen, which pops up a jfilechooser to select a logfile and another jmenuitem, setprefix, which pops up a jdialog to allow the user to type in a file name prefix for downloaded images. 3. There is another jmenuitem that starts the commport running. 4. When logfileopen is pressed before the commport is started, it works. 5. When logfileopen is pressed after the commport is started, it hangs. 6. setprefix works whether or not the commport is started. 7. portIdentifier.open starts a thread that goes into a native method, RXTXPort.eventLoop, and never returns. 8. java.sun bugs has a bug report, 6741890, that is similar but their workaround doesn't. 9. When it locks up, there is a swing-shell thread that appears to be down in some native libraries, winshellfolder2 10. The awt-eventQ thread is unblocked but in code that says its parked. If you have anymore ideas, I'd really appreciate them. wjr Tod E. Kurt wrote: > This is the exact technique I use to let the user choose which serial > port to use on startup. Here's a method I've got in many of my sketches: > > void choosePort() { > String portlist[] = Serial.list(); > String port = null; > javax.swing.SwingUtilities.invokeLater(new Runnable() { > public void run() { > try { > String port = (String) javax.swing.JOptionPane.showInputDialog( > null, > "Select Serial Port", > "MySuperSketch", > javax.swing.JOptionPane.QUESTION_MESSAGE, > null, portlist, null); > if( port == null ) { > javax.swing.JOptionPane.showMessageDialog(null, "No port > chosen, goodbye"); > System.exit(1); > } > serialPort = port; > } > catch (Exception e) { > e.printStackTrace(); > } > } > } ); > } > > > On May 8, 2009, at 2:08 p, Brian Schlining wrote: > >> Bob's probably right...take look at javax.swing.SwingUtilites for the >> workaround to get your swing stuff invoked on the EventDispatchThread >> (EDT). Some swing-methods do work when called outside of the EDT, but >> just to be safe, do your creation and swing calls on the EDT. It's >> really simple, here's an example of a synchronous call. >> >> // Here's how to run stuff on the EDT from a different thread >> SwingUtilities.invokeAndWait(new Runnable() { >> public void run() { >> JFileChooser fc; // create, setup, show your filechooser >> // Get the result from the filechooser >> } >> }); >> >> To do a asynchronous call use SwingUtilities.invokeLater >> >> >> >I wrote a small swing app to download images from an industrial camera. >> >I used the two way serial sample code as a starting point. The app works >> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >> >then try to change the output directory or log file, the jfilechooser >> >winds up trying to unpark (note, parking is not something I'm really >> >familiar with) and doesn't. >> What is the threading structure of your code? >> >> The various high-function Swing components, such as JFileChooser, are >> notorious for doing Really Bad Stuff when invoked from off the Swing >> thread. >> >> Bob >> -- >> Bob Jacobsen, UC Berkeley >> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >> JacobsenRG >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -- >> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >> Brian Schlining >> bschlining at gmail.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx From m.j.tandy at warwick.ac.uk Wed May 13 16:42:24 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 13 May 2009 23:42:24 +0100 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A0B40A6.5070204@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> <4A0B40A6.5070204@weru.ksu.edu> Message-ID: <302aa0340905131542i601ec3f1w3b0b5879c23f8eca@mail.gmail.com> Perhaps you could post your program, or an excerpt of it sufficient to demonstrate the problem you're having, for us to have a look at? 2009/5/13 Bill Rust : > Tod's solution misses the point. He is picking and opening the serial > port. That's the step before where my problem occurs. > > To recap: > > 1. I have a simple java swing app. > 2. On the menu bar, there is the standard set, file, etc., of jmenu's. > Under file, there is a jmenuitem, logfileopen, which pops up a > jfilechooser to select a logfile and another jmenuitem, setprefix, which > pops up a jdialog to allow the user to type in a file name prefix for > downloaded images. > 3. There is another jmenuitem that starts the commport running. > 4. When logfileopen is pressed before the commport is started, it works. > 5. When logfileopen is pressed after the commport is started, it hangs. > 6. setprefix works whether or not the commport is started. > 7. portIdentifier.open starts a thread that goes into a native > method, ? ? ? ? ? ? ? ? ? ? ? ? RXTXPort.eventLoop, and never returns. > 8. java.sun bugs has a bug report, 6741890, that is similar but > their ? ? ? ? ? ? ? ? ? workaround doesn't. > 9. When it locks up, there is a swing-shell thread that appears to be > ? ? ? ?down in some native libraries, winshellfolder2 > 10. The awt-eventQ thread is unblocked but in code that says its parked. > > If you have anymore ideas, I'd really appreciate them. > > wjr > > Tod E. Kurt wrote: >> This is the exact technique I use to let the user choose which serial >> port to use on startup. ?Here's a method I've got in many of my sketches: >> >> void choosePort() { >> ? String portlist[] = Serial.list(); >> ? String port = null; >> ? javax.swing.SwingUtilities.invokeLater(new Runnable() { >> ? ? public void run() { >> ? ? ? try { >> ? ? ? ? String port = (String) javax.swing.JOptionPane.showInputDialog( >> null, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Select Serial Port", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "MySuperSketch", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? javax.swing.JOptionPane.QUESTION_MESSAGE, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? null, portlist, null); >> ? ? ? ? if( port == null ) ?{ >> ? ? ? ? ? javax.swing.JOptionPane.showMessageDialog(null, "No port >> chosen, goodbye"); >> ? ? ? ? ? System.exit(1); >> ? ? ? ? } >> ? ? ? ? serialPort = port; >> ? ? ? } >> ? ? ? catch (Exception e) { >> ? ? ? ? e.printStackTrace(); >> ? ? ? } >> ? ? } >> ? } ); >> } >> >> >> On May 8, 2009, at 2:08 p, Brian Schlining wrote: >> >>> Bob's probably right...take look at javax.swing.SwingUtilites for the >>> workaround to get your swing stuff invoked on the EventDispatchThread >>> (EDT). Some swing-methods do work when called outside of the EDT, but >>> just to be safe, do your creation and swing calls on the EDT. It's >>> really simple, here's an example of a synchronous call. >>> >>> // Here's how to run stuff on the EDT from a different thread >>> SwingUtilities.invokeAndWait(new Runnable() { >>> ? ? ? public void run() { >>> ? ? ? ? ? ?JFileChooser fc; // create, setup, show your filechooser >>> ? ? ? ? ? ?// Get the result from the filechooser >>> ? ? ? } >>> }); >>> >>> To do a asynchronous call use SwingUtilities.invokeLater >>> >>> >>> >I wrote a small swing app to download images from an industrial camera. >>> >I used the two way serial sample code as a starting point. The app works >>> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >>> >then try to change the output directory or log file, the jfilechooser >>> >winds up trying to unpark (note, parking is not something I'm really >>> >familiar with) and doesn't. >>> What is the threading structure of your code? >>> >>> The various high-function Swing components, such as JFileChooser, are >>> notorious for doing Really Bad Stuff when invoked from off the Swing >>> thread. >>> >>> Bob >>> -- >>> Bob Jacobsen, UC Berkeley >>> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >>> JacobsenRG >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >>> -- >>> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >>> Brian Schlining >>> bschlining at gmail.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From m.j.tandy at warwick.ac.uk Thu May 14 03:05:36 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 14 May 2009 10:05:36 +0100 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A0B40A6.5070204@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> <4A0B40A6.5070204@weru.ksu.edu> Message-ID: <302aa0340905140205p6ceb5a9br24e00a50e9cafa5@mail.gmail.com> Java has a built in deadlock detection utility; run your program from the command line, then (on windows) press Ctrl+Break (On Linux, Ctrl+\ does the trick I'm told). That should produce status information and a stack trace for every running thread, including locks held and locks waited on. Maybe that would contain enough information for you to work out what's locking what? 2009/5/13 Bill Rust : > Tod's solution misses the point. He is picking and opening the serial > port. That's the step before where my problem occurs. > > To recap: > > 1. I have a simple java swing app. > 2. On the menu bar, there is the standard set, file, etc., of jmenu's. > Under file, there is a jmenuitem, logfileopen, which pops up a > jfilechooser to select a logfile and another jmenuitem, setprefix, which > pops up a jdialog to allow the user to type in a file name prefix for > downloaded images. > 3. There is another jmenuitem that starts the commport running. > 4. When logfileopen is pressed before the commport is started, it works. > 5. When logfileopen is pressed after the commport is started, it hangs. > 6. setprefix works whether or not the commport is started. > 7. portIdentifier.open starts a thread that goes into a native > method, ? ? ? ? ? ? ? ? ? ? ? ? RXTXPort.eventLoop, and never returns. > 8. java.sun bugs has a bug report, 6741890, that is similar but > their ? ? ? ? ? ? ? ? ? workaround doesn't. > 9. When it locks up, there is a swing-shell thread that appears to be > ? ? ? ?down in some native libraries, winshellfolder2 > 10. The awt-eventQ thread is unblocked but in code that says its parked. > > If you have anymore ideas, I'd really appreciate them. > > wjr > > Tod E. Kurt wrote: >> This is the exact technique I use to let the user choose which serial >> port to use on startup. ?Here's a method I've got in many of my sketches: >> >> void choosePort() { >> ? String portlist[] = Serial.list(); >> ? String port = null; >> ? javax.swing.SwingUtilities.invokeLater(new Runnable() { >> ? ? public void run() { >> ? ? ? try { >> ? ? ? ? String port = (String) javax.swing.JOptionPane.showInputDialog( >> null, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Select Serial Port", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "MySuperSketch", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? javax.swing.JOptionPane.QUESTION_MESSAGE, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? null, portlist, null); >> ? ? ? ? if( port == null ) ?{ >> ? ? ? ? ? javax.swing.JOptionPane.showMessageDialog(null, "No port >> chosen, goodbye"); >> ? ? ? ? ? System.exit(1); >> ? ? ? ? } >> ? ? ? ? serialPort = port; >> ? ? ? } >> ? ? ? catch (Exception e) { >> ? ? ? ? e.printStackTrace(); >> ? ? ? } >> ? ? } >> ? } ); >> } >> >> >> On May 8, 2009, at 2:08 p, Brian Schlining wrote: >> >>> Bob's probably right...take look at javax.swing.SwingUtilites for the >>> workaround to get your swing stuff invoked on the EventDispatchThread >>> (EDT). Some swing-methods do work when called outside of the EDT, but >>> just to be safe, do your creation and swing calls on the EDT. It's >>> really simple, here's an example of a synchronous call. >>> >>> // Here's how to run stuff on the EDT from a different thread >>> SwingUtilities.invokeAndWait(new Runnable() { >>> ? ? ? public void run() { >>> ? ? ? ? ? ?JFileChooser fc; // create, setup, show your filechooser >>> ? ? ? ? ? ?// Get the result from the filechooser >>> ? ? ? } >>> }); >>> >>> To do a asynchronous call use SwingUtilities.invokeLater >>> >>> >>> >I wrote a small swing app to download images from an industrial camera. >>> >I used the two way serial sample code as a starting point. The app works >>> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >>> >then try to change the output directory or log file, the jfilechooser >>> >winds up trying to unpark (note, parking is not something I'm really >>> >familiar with) and doesn't. >>> What is the threading structure of your code? >>> >>> The various high-function Swing components, such as JFileChooser, are >>> notorious for doing Really Bad Stuff when invoked from off the Swing >>> thread. >>> >>> Bob >>> -- >>> Bob Jacobsen, UC Berkeley >>> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >>> JacobsenRG >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >>> -- >>> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >>> Brian Schlining >>> bschlining at gmail.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From cowwoc at bbs.darktech.org Fri May 15 07:18:29 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 09:18:29 -0400 Subject: [Rxtx] InputStream timeouts Message-ID: <4A0D6BA5.8020209@bbs.darktech.org> Why does InputStream.read() return -1 on timeout instead of throwing InterruptedIOException which has existed specifically for this purpose since JDK 1.0? Sockets throw SocketTimeoutException which extends InterruptedIOException. I suspect that this logic confuses BufferedInputStream as well as end-users. Can we introduce this change along with the other timeout-related changes? Gili From Steffen.DETTMER at ingenico.com Fri May 15 07:36:19 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 15 May 2009 15:36:19 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0D6BA5.8020209@bbs.darktech.org> References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <20090515133619.GC17036@elberon.bln.de.ingenico.com> * cowwoc wrote on Fri, May 15, 2009 at 09:18 -0400: > Why does InputStream.read() return -1 on timeout shouldn't it block and only avialable() should care about timeouts? That is how I understand `This method blocks until input data is available' from: http://java.sun.com/j2se/1.5.0/docs/api/java/io/InputStream.html#read() public abstract int read() throws IOException Reads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. A subclass must provide an implementation of this method. Returns: the next byte of data, or -1 if the end of the stream is reached. Throws: IOException - if an I/O error occurs. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Fri May 15 08:22:19 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 15 May 2009 17:22:19 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: >From the javadoc for InputStream: "If no byte is available because the end of the stream has been reached, the value -1 is returned." Since character timeout is not an indication of EOF condition I guess one could argue that 0 should be returned in case of timeout. On the other hand one could also argue that since no data was available (if it timed out) the serial port input stream was at the end of stream (albeit possibly temporarily only). Further the javadoc seems to forbid the return value 0 for Inputstream.read(): " This method blocks until input data is available, the end of the stream is detected, or an exception is thrown." So it can return n >= 1 , -1 or throw an exception. InputStream.read(byte[]) can return 0 but for consistency the options with the other read methods the return value for timeout needs to be -1 or an exception. It goes against my grain to think that I get an exception when I've set up a timeout and I am thus expecting a timeout to happen sometimes. So it is not an exceptional case but expected situation in which case a special return value is philosophically speaking more appropriate. So I'm against changing this behavior. I expect a lot of code depend on the -1 or at least on not getting an exception when a timeout occurs. In any case if an exception were to be thrown it should *not* be InterruptedIOException. >From the javadoc for InterruptedIOException: "An InterruptedIOException is thrown to indicate that an input or output transfer has been terminated because the thread performing it was interrupted. The field bytesTransferred indicates how many bytes were successfully transferred before the interruption occurred" I do not think this matches the case for serial port receive character timeout. I read the javadoc above so that I get this exception when the thread in my code that is performing a read or write operation gets interrupted by Thread.interrupt(). And this is used to handle exactly that case: being able to gracefully and cleanly interrupt threads. my 2 snt worth br Kusti > From: cowwoc > Date: Fri, 15 May 2009 16:18:29 +0300 > To: rxtx > Conversation: [Rxtx] InputStream timeouts > Subject: [Rxtx] InputStream timeouts > > > > Why does InputStream.read() return -1 on timeout instead of > throwing InterruptedIOException which has existed specifically for this > purpose since JDK 1.0? Sockets throw SocketTimeoutException which > extends InterruptedIOException. I suspect that this logic confuses > BufferedInputStream as well as end-users. Can we introduce this change > along with the other timeout-related changes? > > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From cowwoc at bbs.darktech.org Fri May 15 08:35:27 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 10:35:27 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <4A0D7DAF.5030705@bbs.darktech.org> I disagree with your interpretation. Read SocketTimeoutException to see what I mean. InterruptedIOException means the operation was interrupted, not necessarily by way of Thread.interrupt(). Returning 0 in case of timeout sounds wrong to me because it is a legal byte value that could have been read. Returning -1 also sounds wrong to me because this isn't strictly the end of stream. BufferedInputStream and others assume that once you reach the end of stream you will never see more data, ever. As far as I know, the core APIs are written in terms of throwing InterruptedIOException for timeouts. Gili Kustaa Nyholm wrote: > >>From the javadoc for InputStream: > > "If no byte is available because the end of the stream has been reached, the > value -1 is returned." > > > Since character timeout is not an indication of EOF condition I guess one > could argue that 0 should be returned in case of timeout. On the other hand > one could also argue that since no data was available (if it timed out) the > serial port input stream was at the end of stream (albeit possibly > temporarily only). Further the javadoc seems to forbid the return value 0 > for Inputstream.read(): > > " This method blocks until input data is available, the end of the stream is > detected, or an exception is thrown." > > So it can return n >= 1 , -1 or throw an exception. InputStream.read(byte[]) > can return 0 but for consistency the options with the other read methods the > return value for timeout needs to be -1 or an exception. > > It goes against my grain to think that I get an exception when I've set up a > timeout and I am thus expecting a timeout to happen sometimes. So it is not > an exceptional case but expected situation in which case a special return > value is philosophically speaking more appropriate. > > So I'm against changing this behavior. I expect a lot of code depend on the > -1 or at least on not getting an exception when a timeout occurs. > > In any case if an exception were to be thrown it should *not* be > InterruptedIOException. > >>From the javadoc for InterruptedIOException: > > > "An InterruptedIOException is thrown to indicate that an input or output > transfer has been terminated because the thread performing it was > interrupted. The field bytesTransferred indicates how many bytes were > successfully transferred before the interruption occurred" > > I do not think this matches the case for serial port receive character > timeout. I read the javadoc above so that I get this exception when the > thread in my code that is performing a read or write operation gets > interrupted by Thread.interrupt(). And this is used to handle exactly that > case: being able to gracefully and cleanly interrupt threads. > > > > my 2 snt worth br Kusti > > > > >> From: cowwoc >> Date: Fri, 15 May 2009 16:18:29 +0300 >> To: rxtx >> Conversation: [Rxtx] InputStream timeouts >> Subject: [Rxtx] InputStream timeouts >> >> >> >> Why does InputStream.read() return -1 on timeout instead of >> throwing InterruptedIOException which has existed specifically for this >> purpose since JDK 1.0? Sockets throw SocketTimeoutException which >> extends InterruptedIOException. I suspect that this logic confuses >> BufferedInputStream as well as end-users. Can we introduce this change >> along with the other timeout-related changes? >> >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From m.j.tandy at warwick.ac.uk Fri May 15 09:17:36 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Fri, 15 May 2009 16:17:36 +0100 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <302aa0340905150817o39812d7y1b896004a2dcc2ab@mail.gmail.com> > I disagree with your interpretation. Read SocketTimeoutException to see > what I mean. InterruptedIOException means the operation was interrupted, > not necessarily by way of Thread.interrupt(). Strangely enough, the javadoc for InterruptedIOException says: "An InterruptedIOException is thrown to indicate that an input or output transfer has been terminated because the thread performing it was interrupted."[1] But the subclass SocketTimeoutException is used differently - here's an example from sun.net.httpserver.request: /** * block() only called when available==0 and buf is empty */ private synchronized void block () throws IOException { long currtime = server.getTime(); long maxtime = currtime + readTimeout; while (currtime < maxtime) { if (selector.select (readTimeout) == 1) { selector.selectedKeys().clear(); available (); return; } currtime = server.getTime(); } throw new SocketTimeoutException ("no data received"); } So it seems that SocketTimeoutExceptions get thrown not upon thread interruptions, but a certain time after a blocking read is started. [1] http://java.sun.com/javase/6/docs/api/java/io/InterruptedIOException.html From cowwoc at bbs.darktech.org Fri May 15 11:06:53 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 13:06:53 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0DA0F4.9050203@bbs.darktech.org> References: <4A0DA0F4.9050203@bbs.darktech.org> Message-ID: <4A0DA12D.2050303@bbs.darktech.org> Forgot to CC the list. Gili cowwoc wrote: > > "Thread was interrupted" does not necessarily mean > Thread.interrupt(). It just means that the operation (run by the thread) > was interrupted. If you read the beginning sentence for > InterruptedIOException it reads "Signals that an I/O operation has been > interrupted". This says nothing about the thread itself. Michael's > subsequent post about SocketTimeoutException reinforces that point. > > By the way, I think that in general you need to interpret the > Javadoc for core classes in a broader sense than it seems. Older Javadoc > (from version 1.0) used to mention implementation details that were not > necessarily important and limited the applicability of the classes. > Newer documentation tends to go out of its way to avoid mentioning such > implementation detail and I believe that's a good thing. When > InterruptedIOException was written, Thread.interrupt() was probably the > only way to interrupt I/O operations. Nowadays there are others. Sun has > generalized its meaning over time as evident by SocketTimeoutException. > At least, that's my interpretation :) > > Gili > > Kustaa Nyholm wrote: >>> I disagree with your interpretation. Read >>> SocketTimeoutException to >>> see >>> what I mean. InterruptedIOException means the operation was interrupted, >>> not necessarily by way of Thread.interrupt(). >> >> Well SocketTimeoutException javadoc only says, very briefly: >> >> "Signals that a timeout has occurred on a socket read or accept." >> >> So that is not too helpful. But since it is derived from >> InterruptedIOException my interpretation it that they have an 'is-a' >> relationship and InterruptedIOException needs to honor the contract of >> InterruptedIOException which says: >> >> "...because the thread performing it was interrupted." >> >> To me this very specifically talks about interrupting threads with >> Thread.interrupt() >> >> >>> Returning 0 in case of timeout sounds wrong to me because it >>> is a >>> legal >>> byte value that could have been read. >> Agreed, that's what I tried to say. 0 is a legal byte value for read() to >> return so that cannot be used. For read read(byte[]) which returns the >> number of bytes read 0 could be used but there again 0 can be returned >> if 0 >> byte[] size is 0. So there again 0 is not a good option. >> >>> Returning -1 also sounds wrong to >>> me because this isn't strictly the end of stream. >> Like I said, it isn't strictly the end of stream. But also does not >> forbid treating it as (temporary) end of stream. >> >>> BufferedInputStream >>> and others assume that once you reach the end of stream you will never >>> see more data, ever. >> Can you provide a reference for that. >> >>> As far as I know, the core APIs are written in >>> terms of throwing InterruptedIOException for timeouts. >> Would also like to see something to support that. >> >> >> The behavior of throwing an exception on timeout is also a little bit >> problematic, consider: >> >> byte buf[1000]; >> int n=ins.read(buf); >> // do something with the n bytes received >> >> What happens if a timeout occurs before we have received 1000 bytes? >> >> If an exception is thrown then the user of the read() needs to handle >> the bytes received in two places or else those last <1000 bytes are lost. >> A better solution would be to return the bytes received so far and throw >> the exception on the next call (if any). But the main point is that >> neither of these case obviously correct and neither is specified in the >> javadocs. Where as a lot of code that just handles the return value >> of read(byte[]) correctly works without any further ado. >> >> >> >> The main thing is that I think we should not break existing applications, >> which I expect are not handling InterruptedIOException but many of >> which may >> depend on getting back -1 in case of timeouts. >> >> It has been a while since I used the javax.javacomm but I seem to recall >> that it returned -1 and I think this is the defining standard. >> >> I expect most rxtx users are more interested in compatibility and >> stability >> than semantic niceties and improving the API. >> >> br Kusti >> >> >> > From johnny.luong at trustcommerce.com Fri May 15 13:16:15 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Fri, 15 May 2009 12:16:15 -0700 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0DA12D.2050303@bbs.darktech.org> References: <4A0DA0F4.9050203@bbs.darktech.org> <4A0DA12D.2050303@bbs.darktech.org> Message-ID: <4A0DBF7F.50808@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 cowwoc wrote: | Forgot to CC the list. | | Gili | | cowwoc wrote: |> "Thread was interrupted" does not necessarily mean |> Thread.interrupt(). It just means that the operation (run by the thread) |> was interrupted. If you read the beginning sentence for |> InterruptedIOException it reads "Signals that an I/O operation has been |> interrupted". This says nothing about the thread itself. Michael's |> subsequent post about SocketTimeoutException reinforces that point. |> |> By the way, I think that in general you need to interpret the |> Javadoc for core classes in a broader sense than it seems. Older Javadoc |> (from version 1.0) used to mention implementation details that were not |> necessarily important and limited the applicability of the classes. |> Newer documentation tends to go out of its way to avoid mentioning such |> implementation detail and I believe that's a good thing. When |> InterruptedIOException was written, Thread.interrupt() was probably the |> only way to interrupt I/O operations. Nowadays there are others. Sun has |> generalized its meaning over time as evident by SocketTimeoutException. |> At least, that's my interpretation :) |> |> Gili |> |> Kustaa Nyholm wrote: |>>> I disagree with your interpretation. Read |>>> SocketTimeoutException to |>>> see |>>> what I mean. InterruptedIOException means the operation was interrupted, |>>> not necessarily by way of Thread.interrupt(). |>> Well SocketTimeoutException javadoc only says, very briefly: |>> |>> "Signals that a timeout has occurred on a socket read or accept." |>> |>> So that is not too helpful. But since it is derived from |>> InterruptedIOException my interpretation it that they have an 'is-a' |>> relationship and InterruptedIOException needs to honor the contract of |>> InterruptedIOException which says: |>> |>> "...because the thread performing it was interrupted." |>> |>> To me this very specifically talks about interrupting threads with |>> Thread.interrupt() |>> |>> |>>> Returning 0 in case of timeout sounds wrong to me because it |>>> is a |>>> legal |>>> byte value that could have been read. |>> Agreed, that's what I tried to say. 0 is a legal byte value for read() to |>> return so that cannot be used. For read read(byte[]) which returns the |>> number of bytes read 0 could be used but there again 0 can be returned |>> if 0 |>> byte[] size is 0. So there again 0 is not a good option. |>> |>>> Returning -1 also sounds wrong to |>>> me because this isn't strictly the end of stream. |>> Like I said, it isn't strictly the end of stream. But also does not |>> forbid treating it as (temporary) end of stream. |>> |>>> BufferedInputStream |>>> and others assume that once you reach the end of stream you will never |>>> see more data, ever. |>> Can you provide a reference for that. |>> |>>> As far as I know, the core APIs are written in |>>> terms of throwing InterruptedIOException for timeouts. |>> Would also like to see something to support that. |>> |>> |>> The behavior of throwing an exception on timeout is also a little bit |>> problematic, consider: |>> |>> byte buf[1000]; |>> int n=ins.read(buf); |>> // do something with the n bytes received |>> |>> What happens if a timeout occurs before we have received 1000 bytes? |>> |>> If an exception is thrown then the user of the read() needs to handle |>> the bytes received in two places or else those last <1000 bytes are lost. |>> A better solution would be to return the bytes received so far and throw |>> the exception on the next call (if any). But the main point is that |>> neither of these case obviously correct and neither is specified in the |>> javadocs. Where as a lot of code that just handles the return value |>> of read(byte[]) correctly works without any further ado. |>> |>> |>> |>> The main thing is that I think we should not break existing applications, |>> which I expect are not handling InterruptedIOException but many of |>> which may |>> depend on getting back -1 in case of timeouts. |>> |>> It has been a while since I used the javax.javacomm but I seem to recall |>> that it returned -1 and I think this is the defining standard. |>> |>> I expect most rxtx users are more interested in compatibility and |>> stability |>> than semantic niceties and improving the API. |>> |>> br Kusti |>> |>> |>> | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi, Maybe a better approach (improving the API) would be to consider implementing a NIO interface atop the underlying serial communication... ~ if someone desires the existing behavior, then they use a facade that lies atop of the NIO and provide the same quirks associated with it. As I see it, the implementation overrides the general contract of the InputStream to provide for the timeout functionality and it would be somewhat troublesome to expect a user of that API to catch subclasses of IOException. Best, Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoNv38ACgkQnQTBLXttTeWZ+wCeO4CTrI5l+vLPrjHl8fBj7FOL Ft8AnjQ7bXnvMhOlwZdK5CYAuoQeQ9u0 =QAax -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon May 18 03:49:50 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 11:49:50 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <20090518094950.GG17036@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, May 15, 2009 at 17:22 +0300: > >From the javadoc for InputStream: > > Since character timeout is not an indication of EOF condition I > guess one could argue that 0 should be returned in case of > timeout. A blocking operation logically has no timeout. It is blocking. Forever, until EOF or an error. This IMHO renders usage of read() useless and read(byte[]) must be used (or no InputStream). > On the other hand one could also argue that since no data was > available (if it timed out) IMHO, read() must not time out. What would happen with a small simple console app that is relying that InputStream is implemented as required by specification? It cannot tell `no byte was received but this is not an error, please call me again' - and why should it? I think, if this is not suited, i.e. if the application may want a byte but also may not want a byte, no blocking function must be invoked, but a select must be called instead or, if no select-style function is avialable, polling must be used. This is the InputStream way (block or poll). For streams the `may or may not want a byte' may sound unlikely, but in practice this is what happens, for instance, if there is some CANCEL button in a GUI or so. Closing the stream often also is no option because it cannot be reopend but it might be needed again later. In classic unix apps often signals were used (read(2) can return EINTR), but in Java this isn't possible AFAIK. EINTR IMHO has not much relation to InterruptedIOException and I think InterruptedIOException cannot be `enforced' without doing harm. > It goes against my grain to think that I get an exception when > I've set up a timeout yeah, I thought the same and when I hit this InputStream the first time I though: ohh, a bug. Or a bunch of :-) As specified, InputStream has no timeout. If you set a timeout, then somewhere else (e.g. a sub class). In this case, the sub class should also offer a way to wait for this timeout (e.g. a select style function). In practice, this makes not much sense, leaving the options not to use it at all (but what else then?) or to violate the specification. Unfortunately it seems that subclasses add setTimeout but no select() or tryRead() or simply a available()-style with a timeout parameter. Then applications would simply use this subclasses. In practice, then it does not help that they derive InputStream at all, so personally I think they should not derive from it but instead define something with a meaning :-) But I think in practice, for read(byte[]) returning 0 (e.g. in case of [intercharacter] timeout) for many people seems straightforward - so this is probably what most people will expect. (an interesting question is how those bugs happend to the Java guys, because those topics are well known since ages and solved, for instance, in the BSD socket API, but probably they didn't know it. It took years but now it seems they understood and tried it again by some NIO which is more in the `usual way'. Next version might be usable - I wouldn't be surprised if this one then is BSD socket API alike :-) SCNR). So in practice I think: - don't use read() but read(byte[]) or read(byte[], int, int) - handle `0 bytes read' situation - polling avialable() in practice may often not be suited because avialable() has no timeout parameter and if response time is important, small polling intervals would be needed which generate load - try to avoid using InputStream (from applications) directly because it sucks and it is /not/ generic (implementations may interpret it differently because it MUST be interpreted because the specification makes not much sense in many cases) - IOException and InterruptedIOException are for I/O error situations. Additionally I think, InterruptedIOException.bytesTransferred cannot be reliable because there are cases where the OS cannot surely know this and thus cannot tell it the JVM also, peer may have not received them even if they were sent As far as I know this is exactly what rxtx is doing. When having many clients this require many threads and might be less performant, so best is not to have one thousand serial ports :-) Returning 0 here IMHO also is the only option that does not `directly' violate the spec. It tells `there is an attempt to read at least one byte.' so someone could argue that the dear computer `attempted but found no time to do so' :-) > So I'm against changing this behavior. I expect a lot of code > depend on the -1 or at least on not getting an exception when a > timeout occurs. Yes, I agree, -1 means End of file (or closed by peer) and exceptions are for errors. If exceptions should be added I think it could be made configurable. For instance by some Rs232InputStream.enableException(IOException e), store this exception and later if (e != null) throw e.clone() or so. > I do not think this matches the case for serial port receive character > timeout. I read the javadoc above so that I get this exception when the > thread in my code that is performing a read or write operation gets > interrupted by Thread.interrupt(). And this is used to handle exactly that > case: being able to gracefully and cleanly interrupt threads. (well, I think Thread.interrupt() also is a big topic on its own and I'm afraid there is no really reliable mechanism for `cleanly interrupt threads' and maybe even that logically threads cannot be interrupted cleanly at all) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From rxtx at qbang.org Mon May 18 05:17:08 2009 From: rxtx at qbang.org (VIAGRA ® Official Site) Date: Mon, 18 May 2009 05:17:08 -0600 Subject: [Rxtx] DISCOUNT ID42992 75% 0FF on Pfizer ! Message-ID: <200905181117.n4IBH8ku024296@rxtx.qbang.org> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/4c172d08/attachment-0003.html From Kustaa.Nyholm at planmeca.com Mon May 18 07:20:40 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 18 May 2009 16:20:40 +0300 Subject: [Rxtx] InputStream timeouts Message-ID: Oops, sorry sent this to Steffen directly instead of mailing list. So here for the list: > A blocking operation logically has no timeout. It is blocking. > Forever, until EOF or an error. This IMHO renders usage of read() > useless and read(byte[]) must be used (or no InputStream). This is true, however read(byte[]) too is blocking so logically that (allowing it to return with value 0 in case of timeout) is no better (or worse) than read(). According to InputsStream javadoc only when byte[].length is 0 is read(byte[]) non blocking and can return 0. But to be clear: I'm in favor of returning 0 in case of timeouts for read(byte[]) and -1 for read(). > >> On the other hand one could also argue that since no data was >> available (if it timed out) > > IMHO, read() must not time out. IMHO read() should behave consistently with respect to the other read(...) methods. If we allow them to timeout, we should also allow read() to timeout. And in that case we need a return value that separates that case from normal return value (0-255), so -1 seems like a good candidate. > What would happen with a small > simple console app that is relying that InputStream is > implemented as required by specification? It cannot tell `no byte > was received but this is not an error, please call me again' > - and why should it? I think that the simple console app would be just fine, because timeouts are disabled by default so the simple applications are not affected. > > In practice, this makes not much sense, leaving the options not > to use it at all (but what else then?) or to violate the > specification. The javadoc for CommPort.getInputStream() spells out the rules for timeouts: http://java.sun.com/products/javacomm/reference/api/javax/comm/CommPort.html #getInputStream() So, IMO, while it is interesting to discuss these things the javacomm specs is quite clear about blocking behavior and although there is some conflict between how (file) inputstream behaves and Commport inputstreams behave, I think rxtx should adhere to the javacomm spec. > But I think in practice, for read(byte[]) returning 0 (e.g. in > case of [intercharacter] timeout) for many people > seems straightforward - so this is probably what most people will > expect. Agreed, I'm 100% sure there are lots of people out there that use timeouts and depend on the current behavior. Changing this would not help them but infuriate them. > > (well, I think Thread.interrupt() also is a big topic on its own > and I'm afraid there is no really reliable mechanism for > `cleanly interrupt threads' and maybe even that logically > threads cannot be interrupted cleanly at all) Would be interesting to discuss that too but that is beyond the topic of this thread. However I still believe that the InterruptedIOException was introduced so that blocking IO calls could gracefully 'return' if the calling thread was interrupted. Weather this is reliable or clean or graceful could be discussed but to me it seem reasonable. If you have a thread that is blocking on some I/O we need a mechanism that allows stopping that thread in a controlled manner and InterruptedIOException seems to provide this. cheers Kusti From Steffen.DETTMER at ingenico.com Mon May 18 09:18:37 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 17:18:37 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <20090518151837.GS17036@elberon.bln.de.ingenico.com> [OT] * Kustaa Nyholm wrote on Mon, May 18, 2009 at 16:20 +0300: > > A blocking operation logically has no timeout. It is blocking. > > Forever, until EOF or an error. This IMHO renders usage of read() > > useless and read(byte[]) must be used (or no InputStream). > This is true, however read(byte[]) too is blocking so logically that > (allowing it to return with value 0 in case of timeout) is no better > (or worse) than read(). According to InputsStream javadoc only when > byte[].length is 0 is read(byte[]) non blocking and can return 0. I think the essential difference is that for read(byte[]) returning 0 is somewhat clear, but for read() 0 is a valid byte and thus it would be a horrible mess to also use it for timeouts :) > >> On the other hand one could also argue that since no data was > >> available (if it timed out) > > > > IMHO, read() must not time out. > > IMHO read() should behave consistently with respect to the > other read(...) methods. If we allow them to timeout, we should > also allow read() to timeout. And in that case we need a return > value that separates that case from normal return value (0-255), > so -1 seems like a good candidate. Well, but then this is not consistently to EOF handling... (and if read() cannot be consistent, maybe not using it at all is an option?) > > What would happen with a small simple console app that is > > relying that InputStream is implemented as required by > > specification? It cannot tell `no byte was received but this > > is not an error, please call me again' - and why should it? > I think that the simple console app would be just fine, because > timeouts are disabled by default so the simple applications are > not affected. Not setting timeouts IMHO does not mean no timeouts will be applied but that some default timeout is used instead, which could be infinite or some OS value, which in turn may be configurable (like the TCP wait timeouts). > > In practice, this makes not much sense, leaving the options not > > to use it at all (but what else then?) or to violate the > > specification. > > The javadoc for CommPort.getInputStream() spells out the rules for > timeouts: > > http://java.sun.com/products/javacomm/reference/api/javax/comm/CommPort.html > #getInputStream() > So, IMO, while it is interesting to discuss these things > the javacomm specs is quite clear about blocking behavior > and although there is some conflict between how (file) inputstream > behaves and Commport inputstreams behave, I think rxtx should > adhere to the javacomm spec. I think first this does not clearly state what happens a read caller when a timeout occures and second IMHO it does violate the InputStream specification contract (API/javadoc). Formally speaking, it is a bug :-) Also those `advisory methods' in a formal interface are bad, I think. But another topic and discussed already several times :) Yes, in the end it seems the clear correct possiblity (no timeouts) makes no sense, so something pragmatic is needed :-) > > But I think in practice, for read(byte[]) returning 0 (e.g. in > > case of [intercharacter] timeout) for many people > > seems straightforward - so this is probably what most people will > > expect. > Agreed, I'm 100% sure there are lots of people out there that > use timeouts and depend on the current behavior. Changing this > would not help them but infuriate them. yeah, and when shifting to another type of InputStream suddenly they may break, rendering that interface a bit useless, but this is all we have... Correct IMHO would be that the compiler is able to check whether an interface supports timeouts or not (i.e. all methods exist and work as specified or a different interface must be used. Lets say we would have InputStream and InputStreamTimeout or whatever, there would be so many possibilities, but most with own disadvantages). Well, I wonder why they did not even add a timeout parameter to available() and why they forgot about write timeouts completely (also there is no counterpart to available()). Anyway. > > (well, I think Thread.interrupt() also is a big topic on its own > > and I'm afraid there is no really reliable mechanism for > > `cleanly interrupt threads' and maybe even that logically > > threads cannot be interrupted cleanly at all) > Would be interesting to discuss that too but that is beyond the > topic of this thread. However I still believe that the > InterruptedIOException was introduced so that blocking > IO calls could gracefully 'return' if the calling thread > was interrupted. Yes, maybe they forgot it in first place, then found that read can throw IOExceptions only and thus invented InterruptedIOException for InterruptedException-alike cases? but anyway. > Weather this is reliable or clean or graceful could be > discussed but to me it seem reasonable. (With not reliable I mean, when for instance you wanted to write 10 byte and you get this exception telling 5 byte have been written, you cannot be sure what this means. Maybe the 6th byte is in a fifo or whatever. I think best is to avoid the need to handle this). > If you have a thread that is blocking on some I/O we need a > mechanism that allows stopping that thread in a controlled > manner and InterruptedIOException seems to provide this. I think also this is not reliable, because even if the JVM knows a thread is supposed to be `killed', I see at least two issues: first is that native code may be active and cannot be forced to return and second it could be that the thread would need to perform clean up tasks, and since Java does not support RAII (destructors cannot clean), at least you get in trouble when exceptions happening during this cleanup (i.e. exceptions after the thread stops). This in turn IMHO is likely to happen because a well-known situation to interrupt such a thread might be after some error, and after errors exceptions I think happen more often (because less well tested and others). Let's say the thread uses an InputStream (owned by someone else) and now discards it by calling it's close (which should be a delete - because what is an input stream which is closed? Obviously it is not an input stream anymore :-)). Now you might have a special InputStream requiring special things (it might be a protocol requiring some final quit message to be sent, it might need not to close it if used by someone else, too, additional actions may be needed). Logically this could be implemented (turing complete language :-)), but in practice it might not be possible, simply because too complex (to do it right in all circumstances). oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Mon May 18 10:02:39 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 18 May 2009 19:02:39 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: > Not setting timeouts IMHO does not mean no timeouts will be > applied but that some default timeout is used instead, which > could be infinite or some OS value, which in turn may be > configurable (like the TCP wait timeouts). > The javadoc says: "By default, receive timeout is not enabled." and "By default, receive threshold is not enabled." thus (from getInputStream javadoc): "block until any data is available" which is consistent InputStream contract. > I think first this does not clearly state what happens a read > caller when a timeout occures That is true. > and second IMHO it does violate the > InputStream specification contract (API/javadoc). Formally > speaking, it is a bug :-) Agreed, but I think given the advantages you get by using InputStream (as means of reading the serial port as opposed to coming up with some totally new Stream concept) I think this was reasonable compromise and bending of the rules. > yeah, and when shifting to another type of InputStream suddenly > they may break, rendering that interface a bit useless, but this > is all we have... Exactly. > (With not reliable I mean, when for instance you wanted to write > 10 byte and you get this exception telling 5 byte have been > written, you cannot be sure what this means. Maybe the 6th byte > is in a fifo or whatever. I think best is to avoid the need to > handle this). I think all we can assume is that at least 5 bytes have been written into the native driver, weather they are in the fifo or whatever we cannot know. But as you wrote, best avoid depending on this behaviour. > I think also this is not reliable, because even if the JVM knows > a thread is supposed to be `killed', I see at least two issues: > first is that native code may be active and cannot be forced to > return Yes, but this is sort of implementation detail, not an API or Java design issue. The JVM and system class implementations should guarantee this (I bet they don't, consistently, for all platforms and OSes). > and second it could be that the thread would need to > perform clean up tasks, and since Java does not support RAII > (destructors cannot clean), at least you get in trouble when > exceptions happening during this cleanup (i.e. exceptions after > the thread stops). I sort of see what you mean, but still I do not see how this could happen if the cleanup catches exceptions properly. But then I've not studied this in detail. > This in turn IMHO is likely to happen because > a well-known situation to interrupt such a thread might be after > some error, and after errors exceptions I think happen more often > (because less well tested and others). > > Let's say the thread uses an InputStream (owned by someone else) > and now discards it by calling it's close (which should be a > delete - because what is an input stream which is closed? > Obviously it is not an input stream anymore :-)). > Now you might have a special InputStream requiring special things > (it might be a protocol requiring some final quit message to be > sent, it might need not to close it if used by someone else, > too, additional actions may be needed). > Logically this could be implemented (turing complete language :-)), > but in practice it might not be possible, simply because too > complex (to do it right in all circumstances). Ok, I think I understand what you mean: you are saying that what mention aboce "if the cleanup catches exceptions properly" maybe be and often is too difficult/complex to implement and test properly? Yeah, seen that, been there, fallen for it... cheers Kusti From Steffen.DETTMER at ingenico.com Mon May 18 10:39:26 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 18:39:26 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: <20090518163925.GV17036@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Mon, May 18, 2009 at 19:02 +0300: > > Not setting timeouts IMHO does not mean no timeouts will be > > applied but that some default timeout is used instead, which > > could be infinite or some OS value, which in turn may be > > configurable (like the TCP wait timeouts). > > > The javadoc says: > "By default, receive timeout is not enabled." > and > "By default, receive threshold is not enabled." mmm... but they are optional, so what if a driver does not support timeouts but underlaying comm interface does? anyway, *I* would not rely (but loop) but maybe this is not needed. > > and second IMHO it does violate the > > InputStream specification contract (API/javadoc). Formally > > speaking, it is a bug :-) > Agreed, but I think given the advantages you get by using > InputStream (as means of reading the serial port as opposed > to coming up with some totally new Stream concept) I think > this was reasonable compromise and bending of the rules. I don't like InputStream at all. I think it is not an abstraction to remove and later re-add (hack in) needing things. I dislike that noone knows whether it streams bytes or chars or unicode or whatever. Also, I'm used birectional things (`all things are files') for communications, I think it is simpler. So InputStream IMHO is oversimplified. Maybe it was inspired by unix line discipline (but you can select it :-)). Who knows. Anyway. > > I think also this is not reliable, because even if the JVM knows > > a thread is supposed to be `killed', I see at least two issues: > > first is that native code may be active and cannot be forced to > > return > Yes, but this is sort of implementation detail, not an API or > Java design issue. The JVM and system class implementations should > guarantee this (I bet they don't, consistently, for all platforms > and OSes). I think when no reasonable implementation is possible, probably the design is not good. If there is no reasonable way to shutdown (kill) a thread (which is the case IMHO), it makes not much sense to design it. Instead, some mechanism would be needed. I guess the InterruptedException in fact is such a kind of mechanism. I'm not sure but I think Java itself disencourages to use it. > > and second it could be that the thread would need to > > perform clean up tasks, and since Java does not support RAII > > (destructors cannot clean), at least you get in trouble when > > exceptions happening during this cleanup (i.e. exceptions after > > the thread stops). > I sort of see what you mean, but still I do not see how this > could happen if the cleanup catches exceptions properly. But > then I've not studied this in detail. > Ok, I think I understand what you mean: you are saying that > what mention aboce "if the cleanup catches exceptions properly" > maybe be and often is too difficult/complex to implement and > test properly? Yes, since it should work for any implementation, it should work for InputStreams that call abitrary complex read operations. I have applications where the read leads to some CORBA calls to a remote C++ application which also has its complexity. Now in some finally {} exceptions can occure, for instance during member destruction (closing). For example, if you have a facade like implementation with: { old = setMyLogLevel(off); for (i=0; i Yeah, seen that, been there, fallen for it... (welcome in the club :-)) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bill7007 at gmail.com Mon May 18 11:08:45 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 18 May 2009 13:08:45 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090518151837.GS17036@elberon.bln.de.ingenico.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: I can add this thought, I think the timeout is part of a protocol, which should sit above RXTX. The main feature needed in RXTX to support a protocol using timeouts is a way to interrupt it into a known state, like a reset() function. The function should cause an exception to any associated thread that was waiting on IO, maybe a unique exception due to reset() call. An IO (as opposed to Interrupted) exception may be better since the reset() has to leave a known state which may affect IO in progress. I helped work a similar situation in a CAN bus protocol. In the protocol, a send would be followed by a wait for receive. A timeout thread was enabled which caused an "alarm" event to any registered handlers upon timeout. A receive canceled the timeout alarm. The timing and thread coordination is tricky but that is all left to the protocol code. The protocols timeout event handler reset the CAN controller to get it into a known state for a retry. The reset caused an IO exception to the waiting read thread which could check that a timeout had caused it. So, if timeout is considered part of a higher level protocol class, read and write don't need special interface features as long as there is a way for a waiting state in native code to be forced to exit in a reliable, detectable, manner. +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/c9b25045/attachment-0002.html From johnny.luong at trustcommerce.com Mon May 18 11:49:53 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 18 May 2009 10:49:53 -0700 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: <4A119FC1.3090700@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Johnson wrote: | I can add this thought, I think the timeout is part of a protocol, which | should sit above RXTX. The main feature needed in RXTX to support a protocol | using timeouts is a way to interrupt it into a known state, like a reset() | function. The function should cause an exception to any associated thread | that was waiting on IO, maybe a unique exception due to reset() call. An IO | (as opposed to Interrupted) exception may be better since the reset() has to | leave a known state which may affect IO in progress. | | I helped work a similar situation in a CAN bus protocol. In the protocol, a | send would be followed by a wait for receive. A timeout thread was enabled | which caused an "alarm" event to any registered handlers upon timeout. A | receive canceled the timeout alarm. The timing and thread coordination is | tricky but that is all left to the protocol code. The protocols timeout | event handler reset the CAN controller to get it into a known state for a | retry. The reset caused an IO exception to the waiting read thread which | could check that a timeout had caused it. | | So, if timeout is considered part of a higher level protocol class, read and | write don't need special interface features as long as there is a way for a | waiting state in native code to be forced to exit in a reliable, detectable, | manner. | | +BillJ | | | | ------------------------------------------------------------------------ | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx Hi Bill, This is all conjecture and probably a lot of work in practice, so its just a train of thought at this point (via NIO)... Supposer SerialPort were to implement a method that returned "SerialPortChannel" which worked along similar lines as a SocketChannel. ~ Then you could in practice, have a Selector object that did the timeout you described above (via a register method)... your read and write methods could block or not block and it would be a lot easier to drive multiple serial ports than what you have today. - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoRn8EACgkQnQTBLXttTeXm0gCfaua0ej3Rt0fogRR68bbEFG0Z BTwAn1s79U8ZU0yj6xcND8gyHzDmKKqq =ThWj -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon May 18 11:54:10 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 19:54:10 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: <20090518175409.GW17036@elberon.bln.de.ingenico.com> (OT) * Bill Johnson wrote on Mon, May 18, 2009 at 13:08 -0400: > I can add this thought, I think the timeout is part of a > protocol, which should sit above RXTX. Probably actually on both levels timeouts can be helpful; if there is some PPP/TCP or other full duplex multiplexing protcol I think at least it is nice to be able to read with some reasonable timeout(s). > I helped work a similar situation in a CAN bus protocol. In the > protocol, a send would be followed by a wait for receive. A > timeout thread was enabled which caused an "alarm" event to > any registered handlers upon timeout. A receive canceled the > timeout alarm. The timing and thread coordination is tricky but > that is all left to the protocol code. (this Bosch car protocol?) But if the protocol implementation knows the timeout value, wouldn't it be easier and suited better to have some way to apply it to the reads without needing multithreading? Was the implementation in Java? How to cancel the receive by the timeout alarm? Was it (protocol thread implementation) internally polling? You said later, `a way for a waiting state in native code to be forced to exit in a reliable, detectable, manner'. Sounds complicated :) Is this a generic requirement? I think, protocols often can be implemented to use InputStream (or some other interface) but also to offer the same interface (like the decorator pattern). At least when `stacking' such protocols it can become quite difficult, even if having an own thread per protocol instance. Of course heavily depends on the project and situation. Well, interesting topic :) > The protocols timeout event handler reset the CAN controller to > get it into a known state for a retry. The reset caused an IO > exception to the waiting read thread which could check that a > timeout had caused it. Ohh, the CAN controller must be reset? Though they would handle a whole frame automatically. I have no clue about this; surely it is very specific and complex. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bill7007 at gmail.com Mon May 18 12:25:19 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 18 May 2009 14:25:19 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A119FC1.3090700@trustcommerce.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <4A119FC1.3090700@trustcommerce.com> Message-ID: Hi Johnny, I think a SerialPortChannel could be a good example. It uses an underlying Socket which uses an underlying implementation to support open, timeouts, etc. As part of the implementation is where the current RXTX could come in, provided there is a way to back out of a blocking situation. +BillJ On Mon, May 18, 2009 at 1:49 PM, Johnny Luong < johnny.luong at trustcommerce.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Bill Johnson wrote: > | I can add this thought, I think the timeout is part of a protocol, which > | should sit above RXTX. > ... > > Hi Bill, > > This is all conjecture and probably a lot of work in practice, so its > just a train of thought at this point (via NIO)... > > Supposer SerialPort were to implement a method that returned > "SerialPortChannel" which worked along similar lines as a SocketChannel. > ~ Then you could in practice, have a Selector object that did the timeout > you described above (via a register method)... your read and write > methods could block or not block and it would be a lot easier to drive > multiple serial ports than what you have today. > > - -Johnny > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkoRn8EACgkQnQTBLXttTeXm0gCfaua0ej3Rt0fogRR68bbEFG0Z > BTwAn1s79U8ZU0yj6xcND8gyHzDmKKqq > =ThWj > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/0a44a920/attachment-0002.html From lyon at docjava.com Mon May 18 13:18:53 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 18 May 2009 15:18:53 -0400 Subject: [Rxtx] image capture In-Reply-To: References: Message-ID: Hi All, I know this is off-topic, but we have so many native method interface experts here, I just had to ask; Is anyone able to do image capture on a 64 bit mac, using Java? QT4J is not loadable using Java 6 (AFAIK). Thanks! - Doug From bill7007 at gmail.com Mon May 18 13:24:04 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 18 May 2009 15:24:04 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090518175409.GW17036@elberon.bln.de.ingenico.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> Message-ID: On Mon, May 18, 2009 at 1:54 PM, Steffen DETTMER < Steffen.DETTMER at ingenico.com> wrote: > (OT) > > * Bill Johnson wrote on Mon, May 18, 2009 at 13:08 -0400: > > I can add this thought, I think the timeout is part of a > > protocol, which should sit above RXTX. > > Probably actually on both levels timeouts can be helpful; if > there is some PPP/TCP or other full duplex multiplexing protcol I > think at least it is nice to be able to read with some reasonable > timeout(s). I think timeout at the native level does not fit well with a read() concept of timeout because it depends on the protocol not really on the read(). > > > I helped work a similar situation in a CAN bus protocol. In the > > protocol, a send would be followed by a wait for receive. A > > timeout thread was enabled which caused an "alarm" event to > > any registered handlers upon timeout. A receive canceled the > > timeout alarm. The timing and thread coordination is tricky but > > that is all left to the protocol code. > > (this Bosch car protocol?) > > But if the protocol implementation knows the timeout value, > wouldn't it be easier and suited better to have some way to apply > it to the reads without needing multithreading? > If you are waiting on a read and you are waiting on a timeout at the same time, that is two logical threads. Maybe you are looping check for one of two condition, character or timeout, but I think its the same logically as waiting for a character or a timeout exception. It is a special case where you try to read except if it take too long, sound a little like code? > Was the implementation in Java? How to cancel the receive by the > timeout alarm? Was it (protocol thread implementation) internally > polling? > The CAN bus was Java on a TINI embedded system for a warehouse system. It implemented a guaranteed delivery data path patterned after the Datagram interface, I called it a Cangram :-) The problem was how to cancel a read as part of a detected protocol or controller error. The hardware was reset via the native code driver which released resources so a restart was successful. I may have garbaged a thread and started a new one as part of it. > > You said later, `a way for a waiting state in native code to > be forced to exit in a reliable, detectable, manner'. Sounds > complicated :) Is this a generic requirement? I think, protocols > often can be implemented to use InputStream (or some other > interface) but also to offer the same interface (like the > decorator pattern). At least when `stacking' such protocols it > can become quite difficult, even if having an own thread per > protocol instance. Of course heavily depends on the project and > situation. Well, interesting topic :) > I think it (reset, stop, interrupt, whatever) should be a general requirement for any Java native interface code. Without it, your application can lock up and there is no reasonable way to regain control. > > The protocols timeout event handler reset the CAN controller to > > get it into a known state for a retry. The reset caused an IO > > exception to the waiting read thread which could check that a > > timeout had caused it. > > Ohh, the CAN controller must be reset? Though they would handle a > whole frame automatically. > I have no clue about this; surely it is very specific and complex. > The native interface resets it. In most cases, the only reason to reset it was so the native interface was freed up for a retry. If they had a interrupt() function, that may have been better. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. > This message may contain confidential and/or privileged information. If > you are not the addressee or authorized to receive this for the addressee, > you must not use, copy, disclose or take any action based on this message or > any information herein. If you have received this message in error, please > advise the sender immediately by reply e-mail and delete this message. Thank > you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/7df09a1e/attachment-0002.html From beat.arnet at gmail.com Mon May 18 13:27:07 2009 From: beat.arnet at gmail.com (Beat Arnet) Date: Mon, 18 May 2009 15:27:07 -0400 Subject: [Rxtx] Error 0x3e3 at termios.c(1301) Message-ID: All, I am experiencing a situation in which RXTX crashes consistently (both with 2.1 and 2.2). Steps to reproduce: - computer with JAVA program is sending bytes over RS-232 to embedded device, embedded device is off - embedded device powers up and transmit startup banner - JVM crashes: Error 0x3e3 at termios.c(1301) Any idea of what I should be looking for? Thanks! Beat # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6163696c, pid=808, tid=9648 # # Java VM: Java HotSpot(TM) Client VM (1.6.0-b105 mixed mode) # Problematic frame: # C 0x6163696c # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x0af7e400): JavaThread "Thread-4" [_thread_in_native, id=9648] siginfo: ExceptionCode=0xc0000005, reading address 0x6163696c Registers: EAX=0xffffffff, EBX=0x78652064, ECX=0x7c90f661, EDX=0x00000005 ESP=0x0c68f990, EBP=0x70706120, ESI=0x6f207469, EDI=0x6e612072 EIP=0x6163696c, EFLAGS=0x00010206 Top of Stack: (sp=0x0c68f990) 0x0c68f990: 6e6f6974 71657220 74736575 0a0a0d2e 0x0c68f9a0: 00000000 0c68f9d4 6d94556c 0daa3cb4 0x0c68f9b0: 74697277 74794265 3e0d2065 0a000a3e 0x0c68f9c0: 7c90cfea 7c80a059 000007d4 0af7e400 0x0c68f9d0: 6d909d8d 000007d4 00000002 6d945bf6 0x0c68f9e0: 0af7e400 00000001 00000000 0af8b024 0x0c68f9f0: 00000032 0af8b038 00000002 00000000 0x0c68fa00: 00000000 0af7e400 0af8b02c 06e85900 Instructions: (pc=0x6163696c) 0x6163695c: [error occurred during error reporting, step 100, id 0xc0000005] Stack: [0x0c640000,0x0c690000), sp=0x0c68f990, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C 0x6163696c [error occurred during error reporting, step 120, id 0xc0000005] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeByte(IZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write(I)V+86 j codeskin.serial.SerialPortRxtx2_1.write(I)V+29 j codeskin.c2oooprog.BootLoader2xxx$PingTask.run()V+87 v ~StubRoutines::call_stub -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/a692f306/attachment-0002.html From cowwoc at bbs.darktech.org Mon May 18 15:43:15 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Mon, 18 May 2009 17:43:15 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <4A119FC1.3090700@trustcommerce.com> Message-ID: <4A11D673.7080508@bbs.darktech.org> I'm in favor of using SerialPortChannel for timeouts and InputStream for non-blocking reads. This will allow us to follow the specification to the letter without any funky side-effects. In my view breaking the InputStream specification is a far greater sin than throwing InterruptedIOException from read(). Using SerialPortChannel and InputStream should allow us to please people in both camps without breaking the specification. Gili Bill Johnson wrote: > Hi Johnny, > > I think a SerialPortChannel could be a good example. It uses an > underlying Socket which uses an underlying implementation to support > open, timeouts, etc. As part of the implementation is where the current > RXTX could come in, provided there is a way to back out of a blocking > situation. > > +BillJ > > On Mon, May 18, 2009 at 1:49 PM, Johnny Luong > > > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Bill Johnson wrote: > | I can add this thought, I think the timeout is part of a protocol, > which > | should sit above RXTX. > > ... > > > Hi Bill, > > This is all conjecture and probably a lot of work in practice, so its > just a train of thought at this point (via NIO)... > > Supposer SerialPort were to implement a method that returned > "SerialPortChannel" which worked along similar lines as a SocketChannel. > ~ Then you could in practice, have a Selector object that did the > timeout > you described above (via a register method)... your read and write > methods could block or not block and it would be a lot easier to drive > multiple serial ports than what you have today. > > - -Johnny > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkoRn8EACgkQnQTBLXttTeXm0gCfaua0ej3Rt0fogRR68bbEFG0Z > BTwAn1s79U8ZU0yj6xcND8gyHzDmKKqq > =ThWj > -----END PGP SIGNATURE----- > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From bschlining at gmail.com Mon May 18 21:20:25 2009 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 18 May 2009 20:20:25 -0700 Subject: [Rxtx] Fwd: image capture In-Reply-To: References: Message-ID: forgot to cc the list ---------- Forwarded message ---------- From: Brian Schlining Date: Mon, May 18, 2009 at 20:19 Subject: Re: [Rxtx] image capture To: "Dr. Douglas Lyon" > Is anyone able to do image capture on a 64 bit mac, using > Java? Yes, I'm doing it from both video capture cards (Kona and Blackmagic) as well as from movie files. I'm only doing it on Java 5 (Mac) though. > QT4J is not loadable using Java 6 (AFAIK). Are you running this on a Mac or PC? Not that it matters I guess. QT4J is (unofficially) dead. It will be officially deprecated when Mac OS X 10.6 (Snow Leopard) is released, but for all practical purposes it's passed away. With each new release of QuickTime in the past year, I do the mad scramble to work around all the changes and bugs that are introduced. I'm working on once such 'fix' right now as a matter of fact. It's too bad too, QT4J was pretty darn powerful. Your best bet going forward is to rip out the QT4J code and replace it with a Mac/PC/Linux abstraction layer. On a Mac there you could try rococoa ( https://rococoa.dev.java.net) or just grab some QTKit samples off of Apples' developer site and write a JNI or JNA interface. On a PC, not sure what to tell you. I don't know what Apple's plans are with QT4J on a PC. They are pushing everyone away from QuickTime (C API) to QTKit (Cocoa/Objective-C). But on a PC ASFAIK there is no QTKit, so it's still QuickTime in the key of C. -- B ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/913800a4/attachment-0002.html From Kustaa.Nyholm at planmeca.com Tue May 19 00:26:27 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 19 May 2009 09:26:27 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A11D673.7080508@bbs.darktech.org> Message-ID: Oops, did it again, did not send this to the list, so we go: > > I'm in favor of using SerialPortChannel for timeouts and InputStream > for non-blocking reads. This will allow us to follow the specification > to the letter without any funky side-effects. > It was not clear to me what Gili is advocating here so I felt I needed to clarify this. > > In my view breaking the InputStream specification is a far greater sin > than throwing InterruptedIOException from read(). Throwing InterruptedIOException from InputStream.read() is just as big sin as it breaks the contract of InterruptedIOException , which says that the *thread* that was performing the IO was interrupted. Coneceptually I feel throwing an exception is a big sin in a situation which is not an error. A time out in a serial communication is almost always to be excepted since it is used to deal with real, live hardware outside the computer and very often it is a part of the higher level communication protocol, for example used to package or frame messages. Exceptions should be reserved for exceptional things not used for something that the programmer expects to happen normally. For one thing they incur an overhead. Granted, in a typical 9600 baud ie 1ms/char case the overhead is negligible, but it is there. On my 2.8 GHz Core 2 Duo try/throw/catch takes about 13 usec. In my view it is simply wrong to throw an exception for timeouts in a serial port. An even greater sin would be breaking existing code for design purity, at least in this case. > Using > SerialPortChannel and InputStream should allow us to please people in > both camps without breaking the specification. > So you are advocating adding a new class SerialPortChannel and a new method SerialPort.getSerialPortChannel() ? That would be acceptable in that it would not brake existing code but totally unnecessary in my view. I suspect most people turn to rxtx as a replacement for javacomm and are only interested in getting the job done. And the current API does this with very nicely. I think we all have better use for our time than to re-invent a serial port API. If the API bothers someone, I suggest they write a wrapper to implement the improvements and release it for interested users, if any. Would be kind of fun to see them struggle with all the API design issues and see what intellectual compromises they have to concede to. As a famous film ends in the sentence: "Nobody's perfect." cheers Kusti From Steffen.DETTMER at ingenico.com Tue May 19 02:12:14 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 19 May 2009 10:12:14 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A11D673.7080508@bbs.darktech.org> Message-ID: <20090519081214.GY17036@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Tue, May 19, 2009 at 09:26 +0300: > Coneceptually I feel throwing an exception is a big sin in a situation > which is not an error. Yes, I think the same. > In my view it is simply wrong to throw an exception for timeouts in > a serial port. Yes, I agree! > An even greater sin would be breaking existing code for design > purity, at least in this case. An even greater sin than that IMHO would be if the new stuff still isn't undoubtful powerful (which would IMHO need to include the possibility to select serial, TCP and other files simultaneously on systems that support it, e.g. for multi-serial-console applications or so). > So you are advocating adding a new class SerialPortChannel and > a new method SerialPort.getSerialPortChannel() ? SerialPortChannel would be a java.nio.channels.SelectableChannel or so? Or maybe a AbstractGatheringInterruptibleSelectableReadableWritableByteChannel. (the java name for `int fd' lol - SCNR). If changeing, I think an option could be to implement straightforward in native code offering its natural API (full timeout support, maybe as mandatory parameter, not dealing with Channel, Streams, source&sink, reactor&proactor patterns :-)). On top of that then both Channel and Stream and maybe something else for someone else. > That would be acceptable in that it would not brake existing code but > totally unnecessary in my view. I suspect most people turn to rxtx > as a replacement for javacomm and are only interested in getting the > job done. Yes, and most probably just have a few simultaneous connections. Others may need to have a dedicated, specialized and highly optimized JNI impl anyway (I guess). > If the API bothers someone, I suggest they write a wrapper to > implement the improvements and release it for interested users, > if any. Yes, actually that was what we did, but sometimes it was a bit cumbersome (because of InputStream and stuff). We implemented on top of that (instead of native interfaces or such) assuming that those interfaces won't change (but JNI interfaces probably are considered implementation details and thus probably will change). > Would be kind of fun to see them struggle with all the API > design issues and see what intellectual compromises they have > to concede to. Yeah, and then a nio successor comes and everone wanna go with it then :-) oki, Steffen ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Tue May 19 02:33:35 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 19 May 2009 10:33:35 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> Message-ID: <20090519083335.GZ17036@elberon.bln.de.ingenico.com> Hi! * Bill Johnson wrote on Mon, May 18, 2009 at 15:24 -0400: > * On Mon, May 18, 2009 at 1:54 PM, Steffen DETTMER wrote: > > * Bill Johnson wrote on Mon, May 18, 2009 at 13:08 -0400: > > > I can add this thought, I think the timeout is part of a > > > protocol, which should sit above RXTX. > > > > Probably actually on both levels timeouts can be helpful; if > > there is some PPP/TCP or other full duplex multiplexing > > protcol I think at least it is nice to be able to read with > > some reasonable timeout(s). > > I think timeout at the native level does not fit well with a > read() concept of timeout because it depends on the protocol > not really on the read(). What is special about `native level' to gain a special handling? I think all levels should support timeouts. Of course the read timeout an application invokes on a TCP stream has no direct relation to a PPP timeout and intercharacter timeouts on serial lines often depend on serial speed, CPU speed, required response timings, interrupt load etc, I think. So yes, I agree that protocols (often) define needed timeouts (to the lower layer) and the lower layer must offer support for timeouts. Is this what you mean with `depends on the protocol'? > > (this Bosch car protocol?) > > > > But if the protocol implementation knows the timeout value, > > wouldn't it be easier and suited better to have some way to apply > > it to the reads without needing multithreading? > > If you are waiting on a read and you are waiting on a timeout at the same > time, that is two logical threads. Ohh no, I disagree. I think, only if you have plenty of resources it is possible to waste a whole thread to watch a clock. When you have to read 100 connections of course you can use 100 threads, but better would be 1 thread with a select (or epoll or whatever), especially when assuming that the timeout is just a wait (thread sleep) time (when the OS is buffering the data anyway, which on Java running OSes probably is common). > Maybe you are looping check for one of two condition, character > or timeout, but I think its the same logically as waiting for a > character or a timeout exception. It is a special case where > you try to read except if it take too long, sound a little like > code? But isn't a maximum time a natural property of waiting? When you wait for someone for a meeting or so, you look to your watch from time to time and after half an hour or so you leave or continue your business. Select style IMHO is logically more event based than multi-threaded synchronous, but for applications or protocol implementations I found it comfortable when timeouts can be configured at any time. We even have two optional timeout parameters on our read function which eases implementing requirements like `receive both characters within 200 ms or reply with X'. > The CAN bus was Java on a TINI embedded system for a warehouse > system. It implemented a guaranteed delivery data path > patterned after the Datagram interface, I called it a Cangram > :-) The problem was how to cancel a read as part of a detected > protocol or controller error. The hardware was reset via the > native code driver which released resources so a restart was > successful. I may have garbaged a thread and started a new one > as part of it. cool :-) guess this was a very interesting project :) > I think it (reset, stop, interrupt, whatever) should be a > general requirement for any Java native interface code. Without > it, your application can lock up and there is no reasonable way > to regain control. alternatively, it could be required that any JNI function must return after some latest amount of time (i.e. specifying the maximum invocation time). I think, third-path-interruptions, maybe triggered from different threads, could quickly make code complicated because suddenly so many possible code paths can happen and they are hard to test (and cover). Personally, I think this is a major point against avoidable thread usage (even more if threads are not orthogonal) - hard to test, hard to ensure and prove it really is wrong always. Of course often enough it is needed anyway... oki, Steffen ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From michaeltandy at googlemail.com Tue May 19 08:33:09 2009 From: michaeltandy at googlemail.com (Michael Tandy) Date: Tue, 19 May 2009 15:33:09 +0100 Subject: [Rxtx] Rxtx native library loading Message-ID: <302aa0340905190733r4009e394v335b3ef47d84ffb5@mail.gmail.com> Attached is a patch which changes native library loading in Rxtx. Specifically, it makes two changes: 1. Looks in the directory RXTXcomm.jar is in for a native library, prior to searching java.library.path 2. Produces more informative error messages (in addition to the normal exceptions) if the native library cannot be found. The key benefits of this are: (a) to simplify setup; no need for administrator access to put things in shared/system directories, just unzip a file (containing my program as a .jar, RXTXcomm.jar, rxtxSerial.dll, librxtxSerial.so, and so on) and you're good to go; (b) If you've got multiple rxtx versions on your path (e.g. MATLAB puts its bin directory on your path, containing a copy of rxtxSerial.dll) you get the library file matching your jar file; (c) you don't need a big -Djava.library.path= every time you start your program; (d) if your native library file is missing, the error message is a bit more helpful (tells you where is being searched and for what); and (e) If the new code fails, it reverts to what the old code did, so it should be fully backwards-compatible. What do you think - is it worth including these changes in the main version of rxtx? Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: libraryloader.diff Type: text/x-diff Size: 10293 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090519/641c6573/attachment.bin From bill7007 at gmail.com Tue May 19 12:37:32 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Tue, 19 May 2009 14:37:32 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090519083335.GZ17036@elberon.bln.de.ingenico.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> <20090519083335.GZ17036@elberon.bln.de.ingenico.com> Message-ID: On Tue, May 19, 2009 at 4:33 AM, Steffen DETTMER wrote: ... > > Is this what you mean with `depends on the protocol'? Native code is run time speed efficient, and that is important. I think I am saying, design wise, the function is read(). Timeout is a condition on read() only required by whatever comm protocol or comm logic you are using. I am thinking the whole purpose of SerialPort object is to represent a serial port so it should only contains methods and attributes of a serial port. A timeout is an event, part of the communication logic that is using that port. Wow, what a discussion. I had to go back and read it all to gather thoughts. I see multiple issues here. They coexist. 1) CommPort timeout implementation 2) Native blocking behavior and possible interruptions I think my protocol timeout thought was to state that the CommPort timeout may not be the best way implement a protocol timeout, but an alternative needs a blocking interrupt capability. Maybe that should be its own discussion. I do agree with the commandment, Thou shalt not modify the reference API. To focus back on Sun's CommPort interface, it does define a timeout that is optionally implemented and could be useful. I think a description of CommPort.getInputStream together with InputStream.read() leads to the implementation behavior: read() returns "the next byte of data, or -1 if the end of the stream is reached." So, end of stream must mean one of: 1) a timeout 2) "framing errors" (plural meaning parity and overrun too?) read(byte[]?b) returns "the total number of bytes read into the buffer, or -1 is there is no more data because the end of the stream has been reached." An end of stream here causes a return of the number read so far, or -1 if no data was yet read. How to determine cause of end of stream is a weakness of this API. Capturing a SerialPortEvent includes the framing error but not timeout. +BillJ From Steffen.DETTMER at ingenico.com Tue May 19 13:10:26 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 19 May 2009 21:10:26 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> <20090519083335.GZ17036@elberon.bln.de.ingenico.com> Message-ID: <20090519191025.GF17036@elberon.bln.de.ingenico.com> * Bill Johnson wrote on Tue, May 19, 2009 at 14:37 -0400: > methods and attributes of a serial port. A timeout is an event, part > of the communication logic that is using that port. (or the absence of data arrived events?) > read() returns "the next byte of data, or -1 if the end of the stream > is reached." > So, end of stream must mean one of: > 1) a timeout > 2) "framing errors" (plural meaning parity and overrun too?) I think neither timeout nor framing errors are end of stream (end of file) but only `remote DTR drop' is. I'm not sure (and always confuse) to which input line its maps and whether it is hi or lo active... I think, on linux, at least some versions, this worked well because when one side called close(fd) the other side read the EOF in exactly this moment. In general I think this is not reliable (different OSes surely handle it differently and it probably depends on several other things). With TCP sockets this can be expected to work (when one side shuts down its write channel, the other reads EOF after reading all data, which of course is returned first). Well, but probably some OS out there will be different just to annoy us :-) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From cowwoc at bbs.darktech.org Tue May 19 14:28:36 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 19 May 2009 16:28:36 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <4A131674.6000906@bbs.darktech.org> Guys, I am feeling very frustrated with this whole discussion. 1) There is no doubt that the current implementation breaks the InputStream API. A return value of -1 is already mapped to end-of-stream. For this reason, you *cannot* map the same value to a timeout. This is basic design-by-contract! 2) RXTX's implementation does not match javax.comm 100%. There are plenty of situations where the two implementations diverge. I am frustrated that people want to simultaneously freeze the APIs and fix issues that *cannot* be fixed purely in the implementation layer. 3) "Premature optimization is the root of all evil" and yet I see people complaining that exception handling costs 13 usec. Java places emphasizes correctness above performance. If you don't get that you shouldn't be coding in Java. More specific replies below... > Throwing InterruptedIOException from InputStream.read() is just as > big sin as it breaks the contract of InterruptedIOException , which > says that the *thread* that was performing the IO was interrupted. A thread getting interrupted is not the same as Thread.interrupt(). My interpretation is that interrupting the operation due to a timeout is a perfectly legal form of "thread interruption". Even with respect to Thread.interrupt(), you can't interrupt a thread, only the work it is executing. > Coneceptually I feel throwing an exception is a big sin in a situation > which is not an error. Exceptions refer to "exceptional circumstances" which is not the same as "errors". By that I mean that the "normally" the method returns 0-255, but exceptional cases such as timeouts are perfectly legal. > A time out in a serial communication is > almost always to be excepted since it is used to deal with real, live > hardware outside the computer I disagree. Some application-level protocols don't use timeouts at all. Why would your argument be true for serial connections but not sockets? > So you are advocating adding a new class SerialPortChannel and > a new method SerialPort.getSerialPortChannel() ? > > That would be acceptable in that it would not brake existing code but > totally unnecessary in my view. I suspect most people turn to rxtx > as a replacement for javacomm and are only interested in getting the > job done. And the current API does this with very nicely. I think > we all have better use for our time than to re-invent a serial port > API. The classic IO api is synchronous whereas NIO channels are asynchronous. Trying to retrofit timeouts on top of the old APIs will never be as clean as using NIO which is designed specifically for this purpose. Gili From tjarvi at qbang.org Tue May 19 17:19:15 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 May 2009 17:19:15 -0600 (MDT) Subject: [Rxtx] Rxtx native library loading In-Reply-To: <302aa0340905190733r4009e394v335b3ef47d84ffb5@mail.gmail.com> References: <302aa0340905190733r4009e394v335b3ef47d84ffb5@mail.gmail.com> Message-ID: On Tue, 19 May 2009, Michael Tandy wrote: > Attached is a patch which changes native library loading in Rxtx. > > Specifically, it makes two changes: > > 1. Looks in the directory RXTXcomm.jar is in for a native library, > prior to searching java.library.path > 2. Produces more informative error messages (in addition to the normal > exceptions) if the native library cannot be found. > > The key benefits of this are: > (a) to simplify setup; no need for administrator access to put things > in shared/system directories, just unzip a file (containing my program > as a .jar, RXTXcomm.jar, rxtxSerial.dll, librxtxSerial.so, and so on) > and you're good to go; > (b) If you've got multiple rxtx versions on your path (e.g. MATLAB > puts its bin directory on your path, containing a copy of > rxtxSerial.dll) you get the library file matching your jar file; > (c) you don't need a big -Djava.library.path= every time you start your program; > (d) if your native library file is missing, the error message is a bit > more helpful (tells you where is being searched and for what); > and (e) If the new code fails, it reverts to what the old code did, so > it should be fully backwards-compatible. > > What do you think - is it worth including these changes in the main > version of rxtx? > > Michael > Hi Michael, We will be putting a patch like yours in as soon as we release 2.2. The release was going to be mothers day but I got caught up :) I hope to do it next weekend. After that we will be looking at web installs which overlaps with your solution. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 19 17:44:25 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 May 2009 17:44:25 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A131674.6000906@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> Message-ID: On Tue, 19 May 2009, cowwoc wrote: >> A time out in a serial communication is >> almost always to be excepted since it is used to deal with real, live >> hardware outside the computer > > I disagree. Some application-level protocols don't use timeouts at all. > Why would your argument be true for serial connections but not sockets? > Hi Gili One fundamental difference between sockets, file io and RS232 communication is that sockets and file systems provide error handling. If a packet is lost, it is resent without the java API knowing about it. RS232 is actually an electrical signal standard. Serial communication exposes a UART without any meaningful error handling and cludgy error reporting. Given the above, ignoring timeouts is not really a valid rxtx level option. We could have a new option/method that allows you to get an InputStream or Channel that behaves as you wish. If we change the InputStream returned by getInputStream(), that would be change in the API (version 3.0) that forks our userbase. So I guess my question is whether or not you are trying to change the object returned by getInputStream or just looking for a means to get a different object you would like to define be returned. The later is far easier to accommodate. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 19 18:38:06 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 May 2009 18:38:06 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090519191025.GF17036@elberon.bln.de.ingenico.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> <20090519083335.GZ17036@elberon.bln.de.ingenico.com> <20090519191025.GF17036@elberon.bln.de.ingenico.com> Message-ID: On Tue, 19 May 2009, Steffen DETTMER wrote: > * Bill Johnson wrote on Tue, May 19, 2009 at 14:37 -0400: >> methods and attributes of a serial port. A timeout is an event, part >> of the communication logic that is using that port. > > (or the absence of data arrived events?) > >> read() returns "the next byte of data, or -1 if the end of the stream >> is reached." >> So, end of stream must mean one of: >> 1) a timeout >> 2) "framing errors" (plural meaning parity and overrun too?) > > I think neither timeout nor framing errors are end of stream (end > of file) but only `remote DTR drop' is. I'm not sure (and always > confuse) to which input line its maps and whether it is hi or lo > active... > There really is an end of input in termios that would match up fairly close in theory. The problem is it isnt really used as far as I know. termois.c_cc[VEOF] - the end of input character. I assume it is control-d. If you have a terminal open, try typing it into the shell prompt :) We even have some access to it in rxtx as extensions to commapi: private native byte nativeGetEndOfInputChar( ) throws UnsupportedCommOperationException; private native boolean nativeSetEndOfInputChar( byte b ) throws UnsupportedCommOperationException; GPIB has an entire wire dedicated to "EOI." -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue May 19 19:07:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 19 May 2009 21:07:34 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> Message-ID: <4A1357D6.9090705@bbs.darktech.org> Hi Trent, > RS232 is actually an electrical signal standard. Serial communication > exposes a UART without any meaningful error handling and cludgy error > reporting. > > Given the above, ignoring timeouts is not really a valid rxtx level > option. We could have a new option/method that allows you to get an > InputStream or Channel that behaves as you wish. Why? You could always use available() alongside blocking reads. > If we change the InputStream returned by getInputStream(), that would be > change in the API (version 3.0) that forks our userbase. > > So I guess my question is whether or not you are trying to change the > object returned by getInputStream or just looking for a means to get a > different object you would like to define be returned. > > The later is far easier to accommodate. I expect users to use getInputStream() for blocking reads and getInputChannel() for non-blocking reads. I understand your objections and normally I'd agree to wait for version 3.0 but RXTX's violation of the specification is a critical flaw in my opinion. Don't take my word for it... Take a look at this post I just ran across: http://stackoverflow.com/questions/611760/java-inputstream-read-blocking ------ quote ------- A read of -1 isn't doesn't mean, "there's no data present on this attempt," it means, "the stream is closed and there will never be any data so stop asking." If the end of the stream has not been reached, a read() call will block, just as the documentation specifies. [...] I've only used javax.comm for serial port I/O, and it implements InputStream as intended. It's possible that the rxtx implementation violates the contract of InputStream.read(), but if so, that's a very bad thing. Any code that was written to work with InputStream in general relies on the fact that -1 means EOF. Passing a broken java.io.InputStream to such code will cause problems. If rxtx supports non-blocking I/O, they should have created their own interface for reading, not extended InputStream. ------ quote ------- We learn two things from this post: 1) javax.comm respects the InputStream contract. It does not return -1 on timeouts. Seeing how you've written that any deviation from the javax.comm implementation is a bug I would suggest that this should be fixed immediately. 2) Violating the superclass specification can introduce an untold number of bugs. For example, I spent hours trying to figure out why BufferedReader.readLine() was returning null while the connection was still open. Gili From tjarvi at qbang.org Tue May 19 19:23:13 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 May 2009 19:23:13 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A1357D6.9090705@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> Message-ID: On Tue, 19 May 2009, cowwoc wrote: > > 1) javax.comm respects the InputStream contract. It does not return -1 on > timeouts. Seeing how you've written that any deviation from the javax.comm > implementation is a bug I would suggest that this should be fixed > immediately. > Hi Gili What is the observed behavior of javax.comm on timeout? Are you sure it didn't just disable timeouts by default? -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue May 19 19:37:24 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 19 May 2009 21:37:24 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> Message-ID: <4A135ED4.3090608@bbs.darktech.org> Trent Jarvi wrote: >> 1) javax.comm respects the InputStream contract. It does not return -1 >> on timeouts. Seeing how you've written that any deviation from the >> javax.comm implementation is a bug I would suggest that this should be >> fixed immediately. > What is the observed behavior of javax.comm on timeout? Are you sure it > didn't just disable timeouts by default? I'm not sure. Unfortunately, I've never gotten javax.comm to work under Windows and I don't have access to any other platform at this time. I assume that you've used javax.comm before, so I encourage you to try it on your end. Whatever they did, I really don't think that Sun would have violated the InputStream specification by returning -1 on timeout. As the BufferedReader.readLine() example shows, doing so triggers a lot of bugs. Gili From tjarvi at qbang.org Tue May 19 20:01:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 May 2009 20:01:53 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A135ED4.3090608@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> <4A135ED4.3090608@bbs.darktech.org> Message-ID: On Tue, 19 May 2009, cowwoc wrote: > Trent Jarvi wrote: >>> 1) javax.comm respects the InputStream contract. It does not return -1 on >>> timeouts. Seeing how you've written that any deviation from the javax.comm >>> implementation is a bug I would suggest that this should be fixed >>> immediately. > >> What is the observed behavior of javax.comm on timeout? Are you sure it >> didn't just disable timeouts by default? > > I'm not sure. Unfortunately, I've never gotten javax.comm to work > under Windows and I don't have access to any other platform at this time. I > assume that you've used javax.comm before, so I encourage you to try it on > your end. Whatever they did, I really don't think that Sun would have > violated the InputStream specification by returning -1 on timeout. As the > BufferedReader.readLine() example shows, doing so triggers a lot of bugs. > I've actually never used the Sun implementation. RXTX and CommAPI have very different origins that overlap with Kevin Hester's "JCL" patch to bring them together. The rest has been done from the docs. Default settings have always been a source of confusion which is why I ask. Disabled timeouts/thresholds would behave like you expect. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue May 19 20:30:22 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 19 May 2009 22:30:22 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> <4A135ED4.3090608@bbs.darktech.org> Message-ID: <4A136B3E.7010704@bbs.darktech.org> Trent Jarvi wrote: > What is the observed behavior of javax.comm on timeout? Are you sure > it didn't just disable timeouts by default? Can someone who has used javax.comm please investigate this and let us know? Thanks, Gili From Steffen.DETTMER at ingenico.com Wed May 20 02:30:08 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 20 May 2009 10:30:08 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A131674.6000906@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> Message-ID: <20090520083008.GH17036@elberon.bln.de.ingenico.com> * cowwoc wrote on Tue, May 19, 2009 at 16:28 -0400: > Guys, I am feeling very frustrated with this whole discussion. (Me too, but probably for different reason :-)) > 1) There is no doubt that the current implementation breaks the > InputStream API. (which must happen, because InputStream as defined is less usable) > A return value of -1 is already mapped to end-of-stream. For > this reason, you *cannot* map the same value to a timeout. This > is basic design-by-contract! Currently (actually we are still using RXTX-2.1-7 which surely isn't the latest version :)), in case of timeout read(byte[]) returns 0. We have a wrapper implementation (which because of some rxtx timeout precision issues) might be a few lines more than needed but provides timeout precision typical better than 100ms (for us, this is sufficient). I wrote about it here some years ago. So it's possible to work with rxtx even with InputStream. Not very comfortable thanks for InputStream, but it works. Java developers expect InputStream (with its limitations). I was told this several times. May the java and javax APIs suck or not, but it is what most java developers are used to use, expect and what we live with in so many other areas, too. > 2) RXTX's implementation does not match javax.comm 100%. There > are plenty of situations where the two implementations diverge. > I am frustrated that people want to simultaneously freeze the > APIs and fix issues that *cannot* be fixed purely in the > implementation layer. As already written, I think a `real complete exhaustive fix' isn't possible or desired here for various reasons. The current way works well and complies to java stuff as much as possible (the differences are enforced logically and the InputStream specification IMHO is simply wrong). Now why change, requiring people to redevelop their applications or wrappers? Why not alternatively publish one of those wrappers (yours? :-)) under a public license and/or add it to rxtx allowing people that want exceptions allowing them to use configurable exceptions (for example)? > 3) "Premature optimization is the root of all evil" and yet I > see people complaining that exception handling costs 13 usec. > Java places emphasizes correctness above performance. If you > don't get that you shouldn't be coding in Java. In general, also `oversimplification is a root of evil' and IMHO nice examples can be found in Java APIs, but this is the way `everyone' goes. Raping exceptions as return codes IMHO is not a performance problem but a design problem (in a non-RAII-aware language which is not allowing ensured resource cleanups by guaranteed destructors this is a real big problem, IMHO). I don't understand the discussion. We have a read returning number of bytes read. We have situations where no byte is read. Now the API doesn't tell that in this case zero should be returned, but I think this is so damn obvious, isn't it?? > > A time out in a serial communication is almost always to be > > excepted since it is used to deal with real, live hardware > > outside the computer > > I disagree. Some application-level protocols don't use timeouts > at all. Why would your argument be true for serial connections > but not sockets? In general, everything has (or should have) timeouts /or/ be under control of something. Technically, the latter may require use `timeouts in a loop' (some polling). TCP has timeouts, for instance retransmission timeouts. Situations were no timeouts are defined in TCP (was it e.g. FIN_WAIT?) in the past lead to issues. On real OSes there are also UDP sockets, UNIX Domain Sockets and whatever else - and all of them and serial ports can accessed via one and the same API and select'd at the same time: timeout supported is simply built-in. For complex protcols, like TCP, all the heaps of defined timeouts might not be as visible as for serial case, where typical applications handle details themself, but they exist. > The classic IO api is synchronous whereas NIO channels are > asynchronous. Trying to retrofit timeouts on top of the old > APIs will never be as clean as using NIO which is designed > specifically for this purpose. I think classic is BSD socket API, which IMHO looks like a natural evolution of classic unix APIs. Works also for serial and everything (at least on unix and cygwin). I think Java people didn't saw the big picture and tried to simplify but oversimplified, assuming, InputStream could be used for all types of communication. Actually, it even can, but not alone (usually, you additionally need OutputStream and some ioctl). Now of course it was nice and sexy to critise the non-type-safe ioctl and select and to drop it - but this of course is no solution. Just ignoring the difficulties rarely helps. NIO is a bit more BSD socket API style, a step into the direction where everything comes from. Next version might take another step and reach the goal. Who knows. As far as I know none of the issues that lead to NIO (mostly performance and scalability) apply to rxtx. The only thing that seems to appy is that some buggy Javadoc tells InputStream would be blocking, available has no timeout, write timeouts are also not supported - and read(byte[]) never returns 0. Which quickly, easily and straightforward `fixes' the issues. That is what rxtx did. Isn't this fine? oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From m.j.tandy at warwick.ac.uk Wed May 20 03:01:51 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 20 May 2009 10:01:51 +0100 Subject: [Rxtx] InputStream timeouts In-Reply-To: <302aa0340905200201r912d9d0m6c9e1e41e049f1df@mail.gmail.com> References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> <302aa0340905200201r912d9d0m6c9e1e41e049f1df@mail.gmail.com> Message-ID: <302aa0340905200201t13a31a4bq30f60042c50fde63@mail.gmail.com> > 2) Violating the superclass specification can introduce an untold number > of bugs. For example, I spent hours trying to figure out why > BufferedReader.readLine() was returning null while the connection was > still open. We're discussing what the read() method does on timeout - but isn't the failure of BufferedReader.readLine caused by read(byte[] b, int off, int len) returning '0 bytes read' - not caused by what the read() method does on timeout? I mean, when I run the code below (Java 1.6.0_13-b03 / Sun JDK 6) the output is: Attempting to read a line... program called inputstream's read(byte[] b, int off, int len) java.io.IOException: Underlying input stream returned zero bytes ? ? ? ?at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) ? ? ? ?at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) ? ? ? ?at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) ? ? ? ?at java.io.InputStreamReader.read(InputStreamReader.java:167) ? ? ? ?at java.io.BufferedReader.fill(BufferedReader.java:136) ? ? ? ?at java.io.BufferedReader.readLine(BufferedReader.java:299) ? ? ? ?at java.io.BufferedReader.readLine(BufferedReader.java:362) ? ? ? ?at inputstreamtest.Main.main(Main.java:14) And if I look at the source code for StreamDecoder.java [1] I see the following lines: ?283 ? ? ? ? ? ? ? int n = in.read(bb.array(), bb.arrayOffset() + pos, rem); ?284 ? ? ? ? ? ? ? if (n < 0) ?285 ? ? ? ? ? ? ? ? ? return n; ?286 ? ? ? ? ? ? ? if (n == 0) ?287 ? ? ? ? ? ? ? ? ? throw new IOException("Underlying input stream returned zero bytes"); Which kind of makes sense, because the javadoc for read(byte[] b, int off, int len) [2] does explicitly say that "If len is zero, then no bytes are read and 0 is returned; otherwise, there is an attempt to read at least one byte. If no byte is available because the stream is at end of file, the value -1 is returned; otherwise, at least one byte is read and stored into b." Is this the problem that you encountered? Michael [1] http://www.docjar.com/html/api/sun/nio/cs/StreamDecoder.java.html [2] http://java.sun.com/javase/6/docs/api/java/io/InputStream.html#read(byte[],%20int,%20int) // CODE BEGINS HERE package inputstreamtest; import java.io.BufferedReader; import java.io.IOException; import java.io.InputStream; import java.io.InputStreamReader; public class Main { ? ?public static void main(String[] args) { ? ? ? ?BufferedReader in = new BufferedReader(new InputStreamReader(new FakeInputStream())); ? ? ? ?System.out.println("Attempting to read a line..."); ? ? ? ?try { ? ? ? ? ? ?in.readLine(); ? ? ? ?} catch (IOException e) { ? ? ? ? ? ?e.printStackTrace(); ? ? ? ?} ? ?} ? ?private static class FakeInputStream extends InputStream { ? ? ? ?@Override ? ? ? ?public int read(byte[] b, int off, int len) { ? ? ? ? ? ?System.out.println("program called inputstream's read(byte[] b, int off, int len)"); ? ? ? ? ? ?return 0; ? ? ? ?} ? ? ? ?@Override ? ? ? ?public int read() throws IOException { ? ? ? ? ? ?System.out.println("program called inputstream's read()"); ? ? ? ? ? ?return -1; ? ? ? ?} ? ?} } From Steffen.DETTMER at ingenico.com Wed May 20 03:16:20 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 20 May 2009 11:16:20 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> <20090519083335.GZ17036@elberon.bln.de.ingenico.com> <20090519191025.GF17036@elberon.bln.de.ingenico.com> Message-ID: <20090520091620.GI17036@elberon.bln.de.ingenico.com> * Trent Jarvi wrote on Tue, May 19, 2009 at 18:38 -0600: > >I think neither timeout nor framing errors are end of stream (end > >of file) but only `remote DTR drop' is. I'm not sure (and always > >confuse) to which input line its maps and whether it is hi or lo > >active... > > There really is an end of input in termios that would match up > fairly close in theory. The problem is it isnt really used as > far as I know. > > termois.c_cc[VEOF] - the end of input character. I assume it > is control-d. If you have a terminal open, try typing it into > the shell prompt :) Ahh yes, this way it was! (what means `logged out' and why my modem has no carrier?! :)) With a null modem cable and a C++ implementation I tried it and found that you are right, it is working with ^D (but not with DTR as I claimed), thanks for the correction. In `stty raw' ^D is 0x04 but after `stty sane' ^D works as end of input character, as you said. select(2) tells ready for read and read(2) return 0 bytes, which means EOF :-) (Well, in strict pure theory I think this could be considered a property of the terminal line discipline canonical mode, which IMHO could be considered a protocol property) BTW, is someone using this EOF in general? Our C++ implementation supports both it seems it (EOF detection) was never used. I guess it depends on the domain someone is working in? I could imagine that some micro controller control interfaces use that? oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed May 20 03:32:00 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 20 May 2009 11:32:00 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> <20090519083335.GZ17036@elberon.bln.de.ingenico.com> <20090519191025.GF17036@elberon.bln.de.ingenico.com> Message-ID: <20090520093200.GK17036@elberon.bln.de.ingenico.com> ps. our java implementation using RXTX-2.1-7 (surely very old) does not detect the ^D in `stty sane' mode. also, just BTW, about the IOException interruption discussion. When I aborted the java command line test program by ^C, I got IOException: java.io.IOException: Interrupted system call in readArray which IMHO shows that Kusti is right. The code not detecting EOF is similar to: port_.enableReceiveTimeout(intTimeout); bytesRead = port_.getInputStream().read( buffer, totalBytesRead, bytesRequested ); switch (bytesRead) { case -1: readClosedByPeer_ = true; break; case 0: // log interchar timeout if (totalBytesRead > 0) { rs232Logger_.finest( "Intercharacter timeout (" + getByteReadTimeout() + " ms) while reading, might be Ok. Returning " + totalBytesRead + " bytes read so far" ); } if (!ENABLE_RECEIVE_TIMEOUT_PRECISION_LOGGING) { break; } So actually I don't know if readClosedByPeer ever worked (we don't use it anyway I think). oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Wed May 20 03:57:30 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 12:57:30 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <302aa0340905200201t13a31a4bq30f60042c50fde63@mail.gmail.com> Message-ID: > From: Michael Tandy > And if I look at the source code for StreamDecoder.java [1] I see the > following lines: > ?283 ? ? ? ? ? ? ? int n = in.read(bb.array(), bb.arrayOffset() + pos, rem); > ?284 ? ? ? ? ? ? ? if (n < 0) > ?285 ? ? ? ? ? ? ? ? ? return n; > ?286 ? ? ? ? ? ? ? if (n == 0) > ?287 ? ? ? ? ? ? ? ? ? throw new IOException("Underlying input stream > returned zero bytes"); > > Which kind of makes sense, because the javadoc for read(byte[] b, int > off, int len) [2] does explicitly say that "If len is zero, then no > bytes are read and 0 is returned; otherwise, there is an attempt to > read at least one byte. If no byte is available because the stream is > at end of file, the value -1 is returned; otherwise, at least one byte > is read and stored into b." Not realy relevant for the discussion but out of curiosity I had peek at the code you quoted and just a few lines above we see: 278 int lim = bb.limit(); 279 int pos = bb.position(); 280 assert (pos <= lim); 281 int rem = (pos <= lim ? lim - pos : 0); 282 assert rem > 0; If asserts are disabled (the default IIRC) then 'rem' could be 0 in which case throwing exception on line 287 is not correct in that it is legal for read(byte[]) to return under that circumstance. Of course it maybe that the design of StreamDecoder otherwise guarantees that lim > pos but this just shows how difficult it is to be logically consistent all the time. Further browsing the StreamDecoder and CharsetDecorder classes it seems, at least superficially, that nothing has been gained by checking and throwing an exception, the rest of code would have worked correctly even if the the read on line 283 would return 0. All code that I've ever written have handled read(byte[]) returning 0 correctly (touch wood!) taking it on it's stride. Why not, you need to prepare for read to return less than what you asked so it naturally falls to handle the case of 0 also. From Kustaa.Nyholm at planmeca.com Wed May 20 04:06:12 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 13:06:12 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090520083008.GH17036@elberon.bln.de.ingenico.com> Message-ID: > From: Steffen DETTMER > >> 1) There is no doubt that the current implementation breaks the >> InputStream API. > (which must happen, because InputStream as defined is less usable) > Exactly. > Now why change, requiring people to redevelop their applications > or wrappers? Why not alternatively publish one of those wrappers > (yours? :-)) under a public license and/or add it to rxtx > allowing people that want exceptions allowing them to use > configurable exceptions (for example)? > Hear,hear, agree whole heartedly! > > I don't understand the discussion. We have a read returning > number of bytes read. We have situations where no byte is read. > Now the API doesn't tell that in this case zero should be > returned, but I think this is so damn obvious, isn't it?? To me it is soooooo obvious. > > The only thing that seems to appy is that some buggy Javadoc > tells InputStream would be blocking, available has no timeout, > write timeouts are also not supported - and read(byte[]) never > returns 0. Which quickly, easily and straightforward `fixes' the > issues. That is what rxtx did. Isn't this fine? It is fine. It ain't broken, don't fix it. This is mainly a documentation issue. When the map and scenery disagree trust the scenery. Thanks Steffen for summing it up so nicely! cheers Kusti From cowwoc at bbs.darktech.org Wed May 20 04:39:31 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 06:39:31 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090520083008.GH17036@elberon.bln.de.ingenico.com> References: <4A131674.6000906@bbs.darktech.org> <20090520083008.GH17036@elberon.bln.de.ingenico.com> Message-ID: <4A13DDE3.8070703@bbs.darktech.org> Steffen DETTMER wrote: > * cowwoc wrote on Tue, May 19, 2009 at 16:28 -0400: >> Guys, I am feeling very frustrated with this whole discussion. > > (Me too, but probably for different reason :-)) > >> 1) There is no doubt that the current implementation breaks the >> InputStream API. > > (which must happen, because InputStream as defined is less usable) Not true. Either we follow the InputSteam specification or we define our own interface. Breaking the specification in this way will trigger unpredictable bugs. > Currently (actually we are still using RXTX-2.1-7 which surely > isn't the latest version :)), in case of timeout read(byte[]) > returns 0. > > I don't understand the discussion. We have a read returning > number of bytes read. We have situations where no byte is read. > Now the API doesn't tell that in this case zero should be > returned, but I think this is so damn obvious, isn't it?? Actually, the Javadoc for read(byte[]) says that at least one byte must be read: "If the length of b is zero, then no bytes are read and 0 is returned; otherwise, there is an attempt to read at least one byte. If no byte is available because the stream is at the end of the file, the value -1 is returned; otherwise, at least one byte is read and stored into b." > In general, everything has (or should have) timeouts /or/ be > under control of something. Technically, the latter may > require use `timeouts in a loop' (some polling). TCP has > timeouts, for instance retransmission timeouts. Situations were > no timeouts are defined in TCP (was it e.g. FIN_WAIT?) in the > past lead to issues. On real OSes there are also UDP sockets, > UNIX Domain Sockets and whatever else - and all of them and > serial ports can accessed via one and the same API and select'd > at the same time: timeout supported is simply built-in. > For complex protcols, like TCP, all the heaps of defined timeouts > might not be as visible as for serial case, where typical > applications handle details themself, but they exist. Fair enough, but "timeouts in a loop" -- using available() -- don't break the InputStream specification. > NIO is a bit more BSD socket API style, a step into the direction > where everything comes from. Next version might take another step > and reach the goal. Who knows. As far as I know none of the > issues that lead to NIO (mostly performance and scalability) > apply to rxtx. NIO allows you to select() on a channel with a timeout, which is the point of contention. > The only thing that seems to appy is that some buggy Javadoc > tells InputStream would be blocking, available has no timeout, > write timeouts are also not supported - and read(byte[]) never > returns 0. Which quickly, easily and straightforward `fixes' the > issues. That is what rxtx did. Isn't this fine? I'm not sure I understand. I get that you dislike that InputStream doesn't provide facilities for non-blocking reads but that is just life. You're supposed to either create your own interface or use NIO for that. In my view, breaking the superclass contract is always worse than inconveniencing yourself. Gili From cowwoc at bbs.darktech.org Wed May 20 04:41:14 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 06:41:14 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <302aa0340905200201t13a31a4bq30f60042c50fde63@mail.gmail.com> References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> <302aa0340905200201r912d9d0m6c9e1e41e049f1df@mail.gmail.com> <302aa0340905200201t13a31a4bq30f60042c50fde63@mail.gmail.com> Message-ID: <4A13DE4A.70704@bbs.darktech.org> Yes. Gili Michael Tandy wrote: >> 2) Violating the superclass specification can introduce an untold number >> of bugs. For example, I spent hours trying to figure out why >> BufferedReader.readLine() was returning null while the connection was >> still open. > > We're discussing what the read() method does on timeout - but isn't > the failure of BufferedReader.readLine caused by read(byte[] b, int > off, int len) returning '0 bytes read' - not caused by what the read() > method does on timeout? > > I mean, when I run the code below (Java 1.6.0_13-b03 / Sun JDK 6) the output is: > > Attempting to read a line... > program called inputstream's read(byte[] b, int off, int len) > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > at inputstreamtest.Main.main(Main.java:14) > > And if I look at the source code for StreamDecoder.java [1] I see the > following lines: > 283 int n = in.read(bb.array(), bb.arrayOffset() + pos, rem); > 284 if (n < 0) > 285 return n; > 286 if (n == 0) > 287 throw new IOException("Underlying input stream > returned zero bytes"); > > Which kind of makes sense, because the javadoc for read(byte[] b, int > off, int len) [2] does explicitly say that "If len is zero, then no > bytes are read and 0 is returned; otherwise, there is an attempt to > read at least one byte. If no byte is available because the stream is > at end of file, the value -1 is returned; otherwise, at least one byte > is read and stored into b." > > Is this the problem that you encountered? > > Michael > > [1] http://www.docjar.com/html/api/sun/nio/cs/StreamDecoder.java.html > [2] http://java.sun.com/javase/6/docs/api/java/io/InputStream.html#read(byte[],%20int,%20int) > > > // CODE BEGINS HERE > package inputstreamtest; > > import java.io.BufferedReader; > import java.io.IOException; > import java.io.InputStream; > import java.io.InputStreamReader; > > public class Main { > > public static void main(String[] args) { > BufferedReader in = new BufferedReader(new > InputStreamReader(new FakeInputStream())); > System.out.println("Attempting to read a line..."); > try { > in.readLine(); > } catch (IOException e) { > e.printStackTrace(); > } > } > > private static class FakeInputStream extends InputStream { > @Override > public int read(byte[] b, int off, int len) { > System.out.println("program called inputstream's > read(byte[] b, int off, int len)"); > return 0; > } > > @Override > public int read() throws IOException { > System.out.println("program called inputstream's read()"); > return -1; > } > } > > } > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From cowwoc at bbs.darktech.org Wed May 20 04:45:25 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 06:45:25 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <4A13DF45.7030305@bbs.darktech.org> Kustaa Nyholm wrote: > It is fine. It ain't broken, don't fix it. This is mainly > a documentation issue. When the map and scenery disagree trust > the scenery. This isn't "documentation". It's a specification. The core Java APIs implement it perfectly and expect it to be followed 100% of the time. It is impossible to change it this late in the game. Gili From Kustaa.Nyholm at planmeca.com Wed May 20 06:03:15 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 15:03:15 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A131674.6000906@bbs.darktech.org> Message-ID: > > Guys, I am feeling very frustrated with this whole discussion. I feel your pain as I'm frustrated, not by the discussion which has been conducted in a gentlemanly maner and has entertained me quite a lot, but by people trying to fix what ain't broken. > > 1) There is no doubt that the current implementation breaks the > InputStream API. Well, this is like saying my car is broken because a mouse ate the registration paper (honestly, that happened last winter). There is only a very minor discrepancy between what a few document sentences says and what *useful and practical* functionality the current rxtx/javacomm provides. > A return value of -1 is already mapped to > end-of-stream. For this reason, you *cannot* map the same value to a > timeout. This is basic design-by-contract! I thought we already agreed (talking about read(byte[])) 0 should be returned and AFAIK *is* returned. And this matches the javadoc for CommPort.getInputStream() which says that it return a kind of InputStream where read operations blocks until a timeout occurs OR until any data is available. So it can return even when no data is available. And in that case 0 seems like an appropriate return value. It bends the rules of InputStream a bit, but this is by design, not error. Now, if read() returns -1 in case of timeout this is a dilemma as it does allow differentiation between EOF (whatever it means for serial stream) and timeout. However the 'golden standard', the stream object that javacomm.SerialPort.getInputStream().read(), returns in case of timeout is -1, at least on Windows (just tested it). And we should not brake this compatibility. > > 2) RXTX's implementation does not match javax.comm 100%. > So? Why make it match even less? Most people want compatibility and usability, not semantic / logical correctness at least as far as something as small as serial port API is concerned. Go write your own wrapper if it bother you. > There are > plenty of situations where the two implementations diverge. If there are, please let us know, this is very useful information for any rxtx user so that they can avoid these pitfalls. > I am > frustrated that people want to simultaneously freeze the APIs and fix > issues that *cannot* be fixed purely in the implementation layer. What issues you mean? Off hand I don't recall people asking for fixes that would match your description of "that *cannot* be fixed purely in the implementation layer". Personally, all I've ever wanted from javacomm and rxtx was to be able to access the serial port from Java in platform neutral fashion that allows my code to run on the three major platforms Mac OS X, Linux and Windows. And rxtx delivers just that. > > 3) "Premature optimization is the root of all evil" and yet I see people > complaining that exception handling costs 13 usec. I'm sure you understood that 13 usec was not the point. The point is that exception handling concept has been designed to handle exceptional case which are rare and thus performance of the code when an exception is thrown can be slow. The penalty is not specified but includes creating a new object or several (stack trace) and frequently warned about. Like I said, and I'm sure you understood, at 9600 baud this penalty is not an issue, but in a slower machine (mine was, as stated 2.8 GHz/4GB/1066MHz Core 2 Duo), or different JVM, or JIT not happening (BTW exception handling disturbs JIT) it could be a decade slower. So make it 100 usec and raise baud rate to 1 MBps now merely throwing the exception takes ten times longer than a one character timeout. Many protocols I have programmed have used pauses of less than that to frame messages. IMO it would be serious mistake to use exceptions to handle timeouts. Ever wondered why EOF is signaled with -1 and not an exception... > Java places > emphasizes correctness above performance. If you don't get that you > shouldn't be coding in Java. This is not what I would call parliamentary language. I won't reply. > > More specific replies below... > >> Throwing InterruptedIOException from InputStream.read() is just as >> big sin as it breaks the contract of InterruptedIOException , which >> says that the *thread* that was performing the IO was interrupted. > > A thread getting interrupted is not the same as Thread.interrupt(). Oh yeah? Really? In the context it was used I beg to differ. > My interpretation is that interrupting the operation due to a timeout is a > perfectly legal form of "thread interruption". Even with respect to > Thread.interrupt(), you can't interrupt a thread, only the work it is > executing. > >> Coneceptually I feel throwing an exception is a big sin in a situation >> which is not an error. > > Exceptions refer to "exceptional circumstances" which is not the same > as "errors". By that I mean that the "normally" the method returns > 0-255, but exceptional cases such as timeouts are perfectly legal. But timeout with SerialPort usually is not an exceptional case. But I guess you are fixed to your idea that it is. The important thing however is that it is not for me or you to decide and thus it is not for the API to dictate this. > >> A time out in a serial communication is >> almost always to be excepted since it is used to deal with real, live >> hardware outside the computer > > I disagree. Some application-level protocols don't use timeouts at > all. > Why would your argument be true for serial connections but not sockets? What Sockets and application level protocols have got to do with reading a SerialPort/RS232 port and it's timeouts? > >> So you are advocating adding a new class SerialPortChannel and >> a new method SerialPort.getSerialPortChannel() ? >> >> That would be acceptable in that it would not brake existing code but >> totally unnecessary in my view. I suspect most people turn to rxtx >> as a replacement for javacomm and are only interested in getting the >> job done. And the current API does this with very nicely. I think >> we all have better use for our time than to re-invent a serial port >> API. > > The classic IO api is synchronous whereas NIO channels are > asynchronous. Trying to retrofit timeouts on top of the old APIs will > never be as clean as using NIO which is designed specifically for this > purpose. > You maybe right, but the cure is worse than the disease and the first rule of a good doctor is to "do no harm". What you are concerned about is some semantic details what most of us are concerned with is getting the job done. Here are some more thoughts on using exceptions in case you can be bothered. Quoting from Sun's exception handling tutorial: http://java.sun.com/docs/books/tutorial/essential/exceptions/throwing.html "An Exception indicates that a problem occurred" Now, a timeout, to me, is not a problem, but very often an essential part of the communication protocol. Of course for some in some situations it maybe a problem, but that is not for the (communication) API designer to decide or dictate. To me this spells that timeouts should not throw an exception. Also from the same document: "Here's the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception." Following this guideline would dictate that timeout exception should be a checked exception (because surely almost universally the programmer who enables timeouts (disable by default, remember) can and will handle the timeouts in some reasonable way. *Adding a checked exception toInputStream.reads is not possible.* Again this speaks against throwing an exception in case of timeouts. More in the same vein: http://developer.apple.com/documentation/Performance/Conceptual/CodeSpeed/Ar ticles/TuningJavaCode.html#//apple_ref/doc/uid/TP40002329-DontLinkElementID_ 4 "Exception handling in Java is very slow. ... use exceptions only for truly exceptional cases. Do not use exceptions to indicate simple errors from which your code could otherwise recover. Instead, use them only to indicate abnormal conditions that your code does not know how to handle." cheers Kusti From Kustaa.Nyholm at planmeca.com Wed May 20 06:20:34 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 15:20:34 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A13DDE3.8070703@bbs.darktech.org> Message-ID: > > Not true. Either we follow the InputSteam specification or we define > our own interface. Breaking the specification in this way will trigger > unpredictable bugs. Well bugs are by their very nature unpredictable, what? But seriously who are you to dictate "high road or low road"? Who says we (whoever that 'we' are) must either follow 100% or define our own? If 'we' want to take a middle road we surely can. And I'm all for it. Pursuing 100% clean designs is a fruitless goal and I've got better things to do than keep updating my code base to track an ever changing API in pursuit of an unattainable internal and external purity and correctness. > > Fair enough, but "timeouts in a loop" -- using available() -- don't > break the InputStream specification. So why not use it? If you do not touch the enableTimeout() and enableThreshold() methods the SerialPort.InputStream fulfills the contract to the letter. And if you touch them, it fulfills the commitment that creators of the original API made. > You're supposed to either create your own interface or use NIO for that. > In my view, breaking the superclass contract is always worse than > inconveniencing yourself. Why don't you provide a proof of concept framework of classes and interfaces that are internally and externally consistent for us to scrutinize? I bet it will contain one or two compromises and bending of the rules or be totally out of tune what people need or want to use. cheers Kusti From luis.moreira at ntlworld.com Sat May 2 00:39:04 2009 From: luis.moreira at ntlworld.com (luis.moreira at ntlworld.com) Date: Sat, 2 May 2009 7:39:04 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Hi Travis, The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. The issues I still have is the errors after that. Do you have any idea what can be causing this errors? _______________________________________________________________________________ conftest.c: In function 'main': conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) conftest.c:8: error: (Each undeclared identifier is reported only once conftest.c:8: error: for each function it appears in.) conftest.c:8: error: expected ')' before string constant conftest.c:8: warning: format not a string literal and no format arguments ./configure: line 21462: ./conftest: No such file or directory ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands ------------------------------------------------------------------------------- I don't know what happened to my previous post, it as not showed up in the list. Best Regards Luis From tjarvi at qbang.org Sat May 2 07:30:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 07:30:04 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> References: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Message-ID: On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > Hi Travis, > The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. > The issues I still have is the errors after that. Do you have any idea what can be causing this errors? > > _______________________________________________________________________________ > conftest.c: In function 'main': > conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) > conftest.c:8: error: (Each undeclared identifier is reported only once > conftest.c:8: error: for each function it appears in.) > conftest.c:8: error: expected ')' before string constant > conftest.c:8: warning: format not a string literal and no format arguments > ./configure: line 21462: ./conftest: No such file or directory > ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: config.h is unchanged > config.status: executing depfiles commands > ------------------------------------------------------------------------------- > > This was corrected in CVS. I think you can just do the following in the top directory: cvs login: (pw is mousy) cvs update That will get the current fixes. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sat May 2 16:14:50 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sat, 02 May 2009 23:14:50 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FCC5DA.6000700@ntlworld.com> Trent Jarvi wrote: > > > On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > >> Hi Travis, >> The problem with the Makefile is not a problem,When I run ./configure >> I make a new Makefile with the same data in it, hence what I just >> modified is removed. >> The issues I still have is the errors after that. Do you have any >> idea what can be causing this errors? >> >> _______________________________________________________________________________ >> >> conftest.c: In function 'main': >> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >> function) >> conftest.c:8: error: (Each undeclared identifier is reported only once >> conftest.c:8: error: for each function it appears in.) >> conftest.c:8: error: expected ')' before string constant >> conftest.c:8: warning: format not a string literal and no format >> arguments >> ./configure: line 21462: ./conftest: No such file or directory >> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >> expected >> configure: creating ./config.status >> config.status: creating Makefile >> config.status: creating config.h >> config.status: config.h is unchanged >> config.status: executing depfiles commands >> ------------------------------------------------------------------------------- >> >> >> > > This was corrected in CVS. I think you can just do the following in > the top directory: > > cvs login: (pw is mousy) > cvs update > > That will get the current fixes. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, apologies for the mix-up of your name. I managed to get further on by updating CVS, the configure command gets to the end without any errors, it still warns me that it is confused about where to find the jni_md.h but I just edited the Makefile and sorted that out. I then run make, with no parameters following the instructions on the Wiki, but that generated a few more errors: ----------------------------------------------------------------------------------------------------------------------- gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. -I/usr/lib/jvm/java-6-openjdk/include /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' undeclared (first use in this function) /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared identifier is reported only once /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each function it appears in.) libtool: link: `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 ----------------------------------------------------------------------------------------------------------------------- Another question I have is, in which folder will the .so files be placed after make finishes? thank you very much for your help. Best Regards Luis From tjarvi at qbang.org Sat May 2 19:27:08 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 19:27:08 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FCC5DA.6000700@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> Message-ID: On Sat, 2 May 2009, Luis Moreira wrote: > Trent Jarvi wrote: >> >> >> On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: >> >>> Hi Travis, >>> The problem with the Makefile is not a problem,When I run ./configure >>> I make a new Makefile with the same data in it, hence what I just >>> modified is removed. >>> The issues I still have is the errors after that. Do you have any >>> idea what can be causing this errors? >>> >>> _______________________________________________________________________________ >>> >>> conftest.c: In function 'main': >>> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >>> function) >>> conftest.c:8: error: (Each undeclared identifier is reported only once >>> conftest.c:8: error: for each function it appears in.) >>> conftest.c:8: error: expected ')' before string constant >>> conftest.c:8: warning: format not a string literal and no format >>> arguments >>> ./configure: line 21462: ./conftest: No such file or directory >>> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >>> expected >>> configure: creating ./config.status >>> config.status: creating Makefile >>> config.status: creating config.h >>> config.status: config.h is unchanged >>> config.status: executing depfiles commands >>> ------------------------------------------------------------------------------- >>> >>> >>> >> >> This was corrected in CVS. I think you can just do the following in >> the top directory: >> >> cvs login: (pw is mousy) >> cvs update >> >> That will get the current fixes. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > apologies for the mix-up of your name. > I managed to get further on by updating CVS, the configure command gets > to the end without any errors, it still warns me that it is confused > about where to find the jni_md.h but I just edited the Makefile and > sorted that out. > I then run make, with no parameters following the instructions on the > Wiki, but that generated a few more errors: > ----------------------------------------------------------------------------------------------------------------------- > > gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. > -I/usr/lib/jvm/java-6-openjdk/include > /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE > -D_BSD_SOURCE -D__need_timespec -c > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o > /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' > undeclared (first use in this function) > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared > identifier is reported only once > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each > function it appears in.) > libtool: link: > `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a > valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 > ----------------------------------------------------------------------------------------------------------------------- > > Another question I have is, in which folder will the .so files be placed > after make finishes? > > thank you very much for your help. > Ah when you do cvs update pass the -Pd option cvs update -Pd Also, when you run configure, use --disable-PRINTER to only build the serial support. It will make things easier. --disable-LOCKFILES will also be easier to get going until you want to learn about how to prevent multiple applications from reading the same serial port. The link for debugging will describe where the files go. By default, it will install in the JRE/JDK under jre/lib/ext (the jar file) jre/lib/i386 (the .so file) Those are on the proper paths when you use the sun or ibm jdk. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sun May 3 01:30:43 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sun, 03 May 2009 08:30:43 +0100 Subject: [Rxtx] First use of RXTX package In-Reply-To: References: <49FCC5DA.6000700@ntlworld.com> Message-ID: <49FD4823.5080204@ntlworld.com> Ah > > when you do cvs update pass the -Pd option > > cvs update -Pd > > Also, when you run configure, use --disable-PRINTER to only build the > serial support. It will make things easier. --disable-LOCKFILES will > also be easier to get going until you want to learn about how to > prevent multiple applications from reading the same serial port. > > The link for debugging will describe where the files go. By default, > it will install in the JRE/JDK under > > jre/lib/ext (the jar file) > jre/lib/i386 (the .so file) > > Those are on the proper paths when you use the sun or ibm jdk. > > http://rxtx.qbang.org/wiki/index.php/Trouble_shooting > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, It as done it! I think this instructions you gave me should be on the Wiki, I can write them for you if you like. Also on the Wiki when you describe the three methods of installing the RxTx package it is confusing because as far as I can see, you always have to do method 1 or the .so files will not be generated(is this correct?). Then you can if you like change the location with method 1 & 2. Is it possible to modify the .la file to point to different directories for installation and then you can decide where to place the files? In a way I have learned quite a lot about Linux by having to struggle, with your help, to find solutions to the problems I encountered (I am still very new to Linux), but maybe we need to log these problems somewhere to make it less of a struggle for others like me. I have used the PortLister example to test it and it came up with my USB to dual Serial adaptor Ports. I will now explore the RxTx package, before I tackle the windows installation, I will let you know of my experience. Thank you for all your Help. Best Regards Luis From tjarvi at qbang.org Sun May 3 10:37:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 3 May 2009 10:37:50 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FD4823.5080204@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> <49FD4823.5080204@ntlworld.com> Message-ID: On Sun, 3 May 2009, Luis Moreira wrote: > Ah >> >> when you do cvs update pass the -Pd option >> >> cvs update -Pd >> >> Also, when you run configure, use --disable-PRINTER to only build the >> serial support. It will make things easier. --disable-LOCKFILES will >> also be easier to get going until you want to learn about how to >> prevent multiple applications from reading the same serial port. >> >> The link for debugging will describe where the files go. By default, >> it will install in the JRE/JDK under >> >> jre/lib/ext (the jar file) >> jre/lib/i386 (the .so file) >> >> Those are on the proper paths when you use the sun or ibm jdk. >> >> http://rxtx.qbang.org/wiki/index.php/Trouble_shooting >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > It as done it! > I think this instructions you gave me should be on the Wiki, I can write > them for you if you like. Also on the Wiki when you describe the three > methods of installing the RxTx package it is confusing because as far > as I can see, you always have to do method 1 or the .so files will not > be generated(is this correct?). Then you can if you like change the > location with method 1 & 2. Is it possible to modify the .la file to > point to different directories for installation and then you can decide > where to place the files? > In a way I have learned quite a lot about Linux by having to struggle, > with your help, to find solutions to the problems I encountered (I am > still very new to Linux), but maybe we need to log these problems > somewhere to make it less of a struggle for others like me. > > I have used the PortLister example to test it and it came up with my USB > to dual Serial adaptor Ports. > > I will now explore the RxTx package, before I tackle the windows > installation, I will let you know of my experience. > > Thank you for all your Help. > Hi Luis, The locations suggested for first time configuration could be documented in a new wiki page explaining that this is not the recommended general workflow but does help new users that are not worried about having rxtx installed into the JRE. For a professional environment, the user would want to follow the workflow currently on the wiki and keep their JRE clean. Often the user will not be able to add libraries to the JRE and will need to use their home directory or a sandbox. Feel free to add information to the wiki. I'd suggest creating comment in the current page and have the comment link to what worked for you as a first time user new to Linux. You can create a new page with your comments. In the long term, we will be working on an autoinstaller that works over the web. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Mon May 4 09:15:40 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Mon, 04 May 2009 16:15:40 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FF069C.8040406@ntlworld.com> Hi Trent, I have now installed the package on my 64 bit machine and when I run my program I get errors on the attachment. I know it as something to do with the architecture of my system but I can no figure out how to fix it. I have built it from source again, I did not transfer the files from machine to machine. can you please put me in the right direction. Thank you very much for your help. Best Regards Luis -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshoot.png Type: image/png Size: 25753 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090504/141ab5dc/attachment-0017.png From johnny.luong at trustcommerce.com Mon May 4 11:57:08 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 04 May 2009 10:57:08 -0700 Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FF069C.8040406@ntlworld.com> References: <49FF069C.8040406@ntlworld.com> Message-ID: <49FF2C74.90805@trustcommerce.com> Luis Moreira wrote: > Hi Trent, > I have now installed the package on my 64 bit machine and when I run my > program I get errors on the attachment. I know it as something to do > with the architecture of my system but I can no figure out how to fix > it. I have built it from source again, I did not transfer the files from > machine to machine. > can you please put me in the right direction. > Thank you very much for your help. > Best Regards > Luis > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Hi, Does running it on a 64-bit JVM help? Your host environment might be building objects for a 64-bit environment unless you did a cross-compile... -- you can find out by doing something like the following: johnny at spike:~$ java -version java version "1.6.0_0" OpenJDK Runtime Environment (build 1.6.0_0-b11) OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode) johnny at spike:~$ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) -Johnny From huangdongkai at gmail.com Wed May 6 11:06:06 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 01:06:06 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. Message-ID: Dear all, I recompile the rxtxSerial source code by MinGW32 and compile success. But when I run my Application which use rxtxSerial.dll to communicate with serial port, a runtime exception happened and application crash. I have no idea why it can not work, beacuse i have not change any source code of rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I have missed when compile the source code on Window NT? Here below is the output error massage. # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, tid=1360 # # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing windows-x86) # Problematic frame: # V [jvm.dll+0x1b6824] # # An error report file with more information is saved as: # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/32c1e699/attachment-0015.html From tjarvi at qbang.org Wed May 6 20:04:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 May 2009 20:04:10 -0600 (MDT) Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: On Thu, 7 May 2009, dongkai huang wrote: > Dear all, > ????? I recompile the rxtxSerial source code by MinGW32 and compile success. > But when I run my Application which use rxtxSerial.dll to communicate with > serial port, a runtime exception happened and application crash.? I have no > idea why it can not work, beacuse i have not change any source code of > rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I > have missed when compile the source code on Window NT? Here below is the > output error massage. > # > # An unexpected error has been detected by Java Runtime Environment: > # > #? EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, > tid=1360 > # > # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing > windows-x86) > > # Problematic frame: > # V? [jvm.dll+0x1b6824] > # > # An error report file with more information is saved as: > # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log > # > # If you would like to submit a bug report, please visit: > #?? http://java.sun.com/webapps/bugreport/crash.jsp > # > > > Hi Dongkai Could you explain how you compiled rxtx with mingw? Did you run configure? Was the compiler native or a cross compiler (like compiling on Linux for Windows)? Is the crash happening when you first open the port or is it happening randomly later on? -- Trent Jarvi tjarvi at qbang.org From huangdongkai at gmail.com Wed May 6 20:48:56 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 10:48:56 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Hi Trent, I was followed the step on INSTALL file, did not run the configure, I used the Makefile.mingw32 which include on the source code package, and only change some path( jdk home path etc.). And I use the native compiler on Windows. The crash happened on I call the getPortIdentifiers() every time. On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Dear all, >> I recompile the rxtxSerial source code by MinGW32 and compile >> success. >> But when I run my Application which use rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and application crash. I have >> no >> idea why it can not work, beacuse i have not change any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing >> I >> have missed when compile the source code on Window NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is saved as: >> # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> > Hi Dongkai > > Could you explain how you compiled rxtx with mingw? Did you run configure? > Was the compiler native or a cross compiler (like compiling on Linux for > Windows)? > > Is the crash happening when you first open the port or is it happening > randomly later on? > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/733eded5/attachment-0015.html From m.j.tandy at warwick.ac.uk Thu May 7 10:39:12 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 7 May 2009 17:39:12 +0100 Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. Message-ID: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> I've encountered a bug in how XON/XOFF are handled on Windows. The symptoms were: 1. XON/XOFF from device to PC did not stop transmission. 2. XON/XOFF characters were present in data read from serial port input stream, when it was expected that they would be stripped out. 3. Investigation with SysInternals PortMon revealed the following configuration when using rxtx: 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 while HyperTerminal, which did not have the same problems as me, produced the following: 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 In other words, the problem is that, in addition to being told to use XON/XOFF flow control, the computer has to explicitly be told which characters to use for 'XON' and 'XOFF'. This part of the configuration was being missed out. I got the latest rxtx source from CVS, and identified the problem as an omission in the 'init_termios' function of 'termios.c', which configures the unix/termios 'c_cc' (control characters) data structure - but omits to configure the VSTART and VSTOP control characters. Later, the termios c_cc data structure is translated (by termios_to_DCB) into a data structure named 'DCB', which is passed to the windows serial port configuration interface. By adding two lines defining the standard XON/XOFF characters to the function init_termios, the bug is fixed. A patch doing this is attached. Thanks, Michael Tandy -------------- next part -------------- A non-text attachment was scrubbed... Name: xon-xoff.diff Type: application/octet-stream Size: 667 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/159c0dcc/attachment-0014.obj From tjarvi at qbang.org Thu May 7 17:57:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 May 2009 17:57:28 -0600 (MDT) Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. In-Reply-To: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> References: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> Message-ID: On Thu, 7 May 2009, Michael Tandy wrote: > I've encountered a bug in how XON/XOFF are handled on Windows. > > The symptoms were: > 1. XON/XOFF from device to PC did not stop transmission. > 2. XON/XOFF characters were present in data read from serial port > input stream, when it was expected that they would be stripped out. > 3. Investigation with SysInternals PortMon revealed the following > configuration when using rxtx: > > 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 > BRK:0 EVT:a XON:0 XOFF:0 > > while HyperTerminal, which did not have the same problems as me, > produced the following: > > 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 > > In other words, the problem is that, in addition to being told to use > XON/XOFF flow control, the computer has to explicitly be told which > characters to use for 'XON' and 'XOFF'. This part of the configuration > was being missed out. > > I got the latest rxtx source from CVS, and identified the problem as > an omission in the 'init_termios' function of 'termios.c', which > configures the unix/termios 'c_cc' (control characters) data structure > - but omits to configure the VSTART and VSTOP control characters. > Later, the termios c_cc data structure is translated (by > termios_to_DCB) into a data structure named 'DCB', which is passed to > the windows serial port configuration interface. > > By adding two lines defining the standard XON/XOFF characters to the > function init_termios, the bug is fixed. A patch doing this is > attached. > Thanks Michael, Good timing. I plan on releasing rxtx-2.2 this coming Sunday. -- Trent Jarvi tjarvi at qbang.org From wjr at weru.ksu.edu Fri May 8 11:38:29 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Fri, 08 May 2009 12:38:29 -0500 Subject: [Rxtx] swing jfilechooser lockup Message-ID: <4A046E15.6010907@weru.ksu.edu> Hi, I wrote a small swing app to download images from an industrial camera. I used the two way serial sample code as a starting point. The app works fine EXCEPT for a call to jfilechooser. After I open the comm port and then try to change the output directory or log file, the jfilechooser winds up trying to unpark (note, parking is not something I'm really familiar with) and doesn't. If I try to change the file or directory before I start the comm port, it works. If I click on menu items that don't call jfilechooser, everything is OK. If I try closing the comm port and then try to create a jfilechooser, it locks up. There is obviously some sort of deadlock here because the awt thread starts waiting on something but it's not clear what. I haven't gone thru the rxtx code yet because it's not in the file structure that netbeans wants for debugging purposes. However, debugging code that I don't have a clear idea of what it is supposed to do is not my idea of a good time. Does anyone have any ideas on what is going on here? Thanks, wjr From Bob_Jacobsen at lbl.gov Fri May 8 14:48:25 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Fri, 8 May 2009 13:48:25 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A046E15.6010907@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> Message-ID: At 12:38 PM -0500 5/8/09, Bill Rust wrote: >Hi, > >I wrote a small swing app to download images from an industrial camera. >I used the two way serial sample code as a starting point. The app works >fine EXCEPT for a call to jfilechooser. After I open the comm port and >then try to change the output directory or log file, the jfilechooser >winds up trying to unpark (note, parking is not something I'm really >familiar with) and doesn't. If I try to change the file or directory >before I start the comm port, it works. If I click on menu items that >don't call jfilechooser, everything is OK. If I try closing the comm >port and then try to create a jfilechooser, it locks up. There is >obviously some sort of deadlock here because the awt thread starts >waiting on something but it's not clear what. I haven't gone thru the >rxtx code yet because it's not in the file structure that netbeans wants >for debugging purposes. However, debugging code that I don't have a >clear idea of what it is supposed to do is not my idea of a good time. What is the threading structure of your code? The various high-function Swing components, such as JFileChooser, are notorious for doing Really Bad Stuff when invoked from off the Swing thread. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From bschlining at gmail.com Fri May 8 15:08:50 2009 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 8 May 2009 14:08:50 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: Bob's probably right...take look at javax.swing.SwingUtilites for the workaround to get your swing stuff invoked on the EventDispatchThread (EDT). Some swing-methods do work when called outside of the EDT, but just to be safe, do your creation and swing calls on the EDT. It's really simple, here's an example of a synchronous call. // Here's how to run stuff on the EDT from a different thread SwingUtilities.invokeAndWait(new Runnable() { public void run() { JFileChooser fc; // create, setup, show your filechooser // Get the result from the filechooser } }); To do a asynchronous call use SwingUtilities.invokeLater > >I wrote a small swing app to download images from an industrial camera. > >I used the two way serial sample code as a starting point. The app works > >fine EXCEPT for a call to jfilechooser. After I open the comm port and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090508/c21c2127/attachment-0013.html From tod at todbot.com Fri May 8 16:27:12 2009 From: tod at todbot.com (Tod E. Kurt) Date: Fri, 8 May 2009 15:27:12 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> This is the exact technique I use to let the user choose which serial port to use on startup. Here's a method I've got in many of my sketches: void choosePort() { String portlist[] = Serial.list(); String port = null; javax.swing.SwingUtilities.invokeLater(new Runnable() { public void run() { try { String port = (String) javax.swing.JOptionPane.showInputDialog( null, "Select Serial Port", "MySuperSketch", javax.swing.JOptionPane.QUESTION_MESSAGE, null, portlist, null); if( port == null ) { javax.swing.JOptionPane.showMessageDialog(null, "No port chosen, goodbye"); System.exit(1); } serialPort = port; } catch (Exception e) { e.printStackTrace(); } } } ); } On May 8, 2009, at 2:08 p, Brian Schlining wrote: > Bob's probably right...take look at javax.swing.SwingUtilites for > the workaround to get your swing stuff invoked on the > EventDispatchThread (EDT). Some swing-methods do work when called > outside of the EDT, but just to be safe, do your creation and swing > calls on the EDT. It's really simple, here's an example of a > synchronous call. > > // Here's how to run stuff on the EDT from a different thread > SwingUtilities.invokeAndWait(new Runnable() { > public void run() { > JFileChooser fc; // create, setup, show your filechooser > // Get the result from the filechooser > } > }); > > To do a asynchronous call use SwingUtilities.invokeLater > > > >I wrote a small swing app to download images from an industrial > camera. > >I used the two way serial sample code as a starting point. The app > works > >fine EXCEPT for a call to jfilechooser. After I open the comm port > and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From huangdongkai at gmail.com Sat May 9 04:46:22 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Sat, 9 May 2009 18:46:22 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Dear Trent, After I intsall the ming32-cross compile to compile the rxtxSerial.dll and testing, i found the same problem still exist. I am not sure my compiler version is the same as your's. Could you tell me the way you can success compile rxtx-2.1-7r2 release source code? Thanks for you kindly help. On Fri, May 8, 2009 at 8:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Hi Trent, >> The attach is the Make file I use to compile the rxtx. >> >> On Thu, May 7, 2009 at 10:48 AM, dongkai huang >> wrote: >> Hi Trent, >> I was followed the step on INSTALL file, did not run the >> configure, I used the Makefile.mingw32 which include on the >> source code package, and only change some path( jdk home path >> etc.). And I use the native compiler on Windows. >> The crash happened on I call the getPortIdentifiers() >> every time. >> >> On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: >> >> >> On Thu, 7 May 2009, dongkai huang wrote: >> >> Dear all, >> I recompile the rxtxSerial source code by >> MinGW32 and compile success. >> But when I run my Application which use >> rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and >> application crash. I have no >> idea why it can not work, beacuse i have not change >> any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source >> code. Did some thing I >> have missed when compile the source code on Window >> NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java >> Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at >> pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 >> mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is >> saved as: >> # >> D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please >> visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> >> Hi Dongkai >> >> Could you explain how you compiled rxtx with mingw? Did you run >> configure? Was the compiler native or a cross compiler (like >> compiling on Linux for Windows)? >> >> Is the crash happening when you first open the port or is it >> happening randomly later on? >> >> > Thanks Dongkai > > I'll look at your Makefile tomorrow. Which version of mingw was this? > > I suspect there is a problem with that makefile. I usually built that > version of rxtx for windows with a mingw32 cross compiler using the > configure script. > > The configure script may well work for you if you have a cygwin environment > with mingw instead of gcc. I'll take a look at what is different. > > -- > > Trent Jarvi > tjarvi at qbang.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090509/b729c429/attachment-0013.html From wjr at weru.ksu.edu Wed May 13 15:50:30 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Wed, 13 May 2009 16:50:30 -0500 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> Message-ID: <4A0B40A6.5070204@weru.ksu.edu> Tod's solution misses the point. He is picking and opening the serial port. That's the step before where my problem occurs. To recap: 1. I have a simple java swing app. 2. On the menu bar, there is the standard set, file, etc., of jmenu's. Under file, there is a jmenuitem, logfileopen, which pops up a jfilechooser to select a logfile and another jmenuitem, setprefix, which pops up a jdialog to allow the user to type in a file name prefix for downloaded images. 3. There is another jmenuitem that starts the commport running. 4. When logfileopen is pressed before the commport is started, it works. 5. When logfileopen is pressed after the commport is started, it hangs. 6. setprefix works whether or not the commport is started. 7. portIdentifier.open starts a thread that goes into a native method, RXTXPort.eventLoop, and never returns. 8. java.sun bugs has a bug report, 6741890, that is similar but their workaround doesn't. 9. When it locks up, there is a swing-shell thread that appears to be down in some native libraries, winshellfolder2 10. The awt-eventQ thread is unblocked but in code that says its parked. If you have anymore ideas, I'd really appreciate them. wjr Tod E. Kurt wrote: > This is the exact technique I use to let the user choose which serial > port to use on startup. Here's a method I've got in many of my sketches: > > void choosePort() { > String portlist[] = Serial.list(); > String port = null; > javax.swing.SwingUtilities.invokeLater(new Runnable() { > public void run() { > try { > String port = (String) javax.swing.JOptionPane.showInputDialog( > null, > "Select Serial Port", > "MySuperSketch", > javax.swing.JOptionPane.QUESTION_MESSAGE, > null, portlist, null); > if( port == null ) { > javax.swing.JOptionPane.showMessageDialog(null, "No port > chosen, goodbye"); > System.exit(1); > } > serialPort = port; > } > catch (Exception e) { > e.printStackTrace(); > } > } > } ); > } > > > On May 8, 2009, at 2:08 p, Brian Schlining wrote: > >> Bob's probably right...take look at javax.swing.SwingUtilites for the >> workaround to get your swing stuff invoked on the EventDispatchThread >> (EDT). Some swing-methods do work when called outside of the EDT, but >> just to be safe, do your creation and swing calls on the EDT. It's >> really simple, here's an example of a synchronous call. >> >> // Here's how to run stuff on the EDT from a different thread >> SwingUtilities.invokeAndWait(new Runnable() { >> public void run() { >> JFileChooser fc; // create, setup, show your filechooser >> // Get the result from the filechooser >> } >> }); >> >> To do a asynchronous call use SwingUtilities.invokeLater >> >> >> >I wrote a small swing app to download images from an industrial camera. >> >I used the two way serial sample code as a starting point. The app works >> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >> >then try to change the output directory or log file, the jfilechooser >> >winds up trying to unpark (note, parking is not something I'm really >> >familiar with) and doesn't. >> What is the threading structure of your code? >> >> The various high-function Swing components, such as JFileChooser, are >> notorious for doing Really Bad Stuff when invoked from off the Swing >> thread. >> >> Bob >> -- >> Bob Jacobsen, UC Berkeley >> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >> JacobsenRG >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -- >> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >> Brian Schlining >> bschlining at gmail.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx From m.j.tandy at warwick.ac.uk Wed May 13 16:42:24 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 13 May 2009 23:42:24 +0100 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A0B40A6.5070204@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> <4A0B40A6.5070204@weru.ksu.edu> Message-ID: <302aa0340905131542i601ec3f1w3b0b5879c23f8eca@mail.gmail.com> Perhaps you could post your program, or an excerpt of it sufficient to demonstrate the problem you're having, for us to have a look at? 2009/5/13 Bill Rust : > Tod's solution misses the point. He is picking and opening the serial > port. That's the step before where my problem occurs. > > To recap: > > 1. I have a simple java swing app. > 2. On the menu bar, there is the standard set, file, etc., of jmenu's. > Under file, there is a jmenuitem, logfileopen, which pops up a > jfilechooser to select a logfile and another jmenuitem, setprefix, which > pops up a jdialog to allow the user to type in a file name prefix for > downloaded images. > 3. There is another jmenuitem that starts the commport running. > 4. When logfileopen is pressed before the commport is started, it works. > 5. When logfileopen is pressed after the commport is started, it hangs. > 6. setprefix works whether or not the commport is started. > 7. portIdentifier.open starts a thread that goes into a native > method, ? ? ? ? ? ? ? ? ? ? ? ? RXTXPort.eventLoop, and never returns. > 8. java.sun bugs has a bug report, 6741890, that is similar but > their ? ? ? ? ? ? ? ? ? workaround doesn't. > 9. When it locks up, there is a swing-shell thread that appears to be > ? ? ? ?down in some native libraries, winshellfolder2 > 10. The awt-eventQ thread is unblocked but in code that says its parked. > > If you have anymore ideas, I'd really appreciate them. > > wjr > > Tod E. Kurt wrote: >> This is the exact technique I use to let the user choose which serial >> port to use on startup. ?Here's a method I've got in many of my sketches: >> >> void choosePort() { >> ? String portlist[] = Serial.list(); >> ? String port = null; >> ? javax.swing.SwingUtilities.invokeLater(new Runnable() { >> ? ? public void run() { >> ? ? ? try { >> ? ? ? ? String port = (String) javax.swing.JOptionPane.showInputDialog( >> null, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Select Serial Port", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "MySuperSketch", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? javax.swing.JOptionPane.QUESTION_MESSAGE, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? null, portlist, null); >> ? ? ? ? if( port == null ) ?{ >> ? ? ? ? ? javax.swing.JOptionPane.showMessageDialog(null, "No port >> chosen, goodbye"); >> ? ? ? ? ? System.exit(1); >> ? ? ? ? } >> ? ? ? ? serialPort = port; >> ? ? ? } >> ? ? ? catch (Exception e) { >> ? ? ? ? e.printStackTrace(); >> ? ? ? } >> ? ? } >> ? } ); >> } >> >> >> On May 8, 2009, at 2:08 p, Brian Schlining wrote: >> >>> Bob's probably right...take look at javax.swing.SwingUtilites for the >>> workaround to get your swing stuff invoked on the EventDispatchThread >>> (EDT). Some swing-methods do work when called outside of the EDT, but >>> just to be safe, do your creation and swing calls on the EDT. It's >>> really simple, here's an example of a synchronous call. >>> >>> // Here's how to run stuff on the EDT from a different thread >>> SwingUtilities.invokeAndWait(new Runnable() { >>> ? ? ? public void run() { >>> ? ? ? ? ? ?JFileChooser fc; // create, setup, show your filechooser >>> ? ? ? ? ? ?// Get the result from the filechooser >>> ? ? ? } >>> }); >>> >>> To do a asynchronous call use SwingUtilities.invokeLater >>> >>> >>> >I wrote a small swing app to download images from an industrial camera. >>> >I used the two way serial sample code as a starting point. The app works >>> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >>> >then try to change the output directory or log file, the jfilechooser >>> >winds up trying to unpark (note, parking is not something I'm really >>> >familiar with) and doesn't. >>> What is the threading structure of your code? >>> >>> The various high-function Swing components, such as JFileChooser, are >>> notorious for doing Really Bad Stuff when invoked from off the Swing >>> thread. >>> >>> Bob >>> -- >>> Bob Jacobsen, UC Berkeley >>> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >>> JacobsenRG >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >>> -- >>> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >>> Brian Schlining >>> bschlining at gmail.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From m.j.tandy at warwick.ac.uk Thu May 14 03:05:36 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 14 May 2009 10:05:36 +0100 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A0B40A6.5070204@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> <4A0B40A6.5070204@weru.ksu.edu> Message-ID: <302aa0340905140205p6ceb5a9br24e00a50e9cafa5@mail.gmail.com> Java has a built in deadlock detection utility; run your program from the command line, then (on windows) press Ctrl+Break (On Linux, Ctrl+\ does the trick I'm told). That should produce status information and a stack trace for every running thread, including locks held and locks waited on. Maybe that would contain enough information for you to work out what's locking what? 2009/5/13 Bill Rust : > Tod's solution misses the point. He is picking and opening the serial > port. That's the step before where my problem occurs. > > To recap: > > 1. I have a simple java swing app. > 2. On the menu bar, there is the standard set, file, etc., of jmenu's. > Under file, there is a jmenuitem, logfileopen, which pops up a > jfilechooser to select a logfile and another jmenuitem, setprefix, which > pops up a jdialog to allow the user to type in a file name prefix for > downloaded images. > 3. There is another jmenuitem that starts the commport running. > 4. When logfileopen is pressed before the commport is started, it works. > 5. When logfileopen is pressed after the commport is started, it hangs. > 6. setprefix works whether or not the commport is started. > 7. portIdentifier.open starts a thread that goes into a native > method, ? ? ? ? ? ? ? ? ? ? ? ? RXTXPort.eventLoop, and never returns. > 8. java.sun bugs has a bug report, 6741890, that is similar but > their ? ? ? ? ? ? ? ? ? workaround doesn't. > 9. When it locks up, there is a swing-shell thread that appears to be > ? ? ? ?down in some native libraries, winshellfolder2 > 10. The awt-eventQ thread is unblocked but in code that says its parked. > > If you have anymore ideas, I'd really appreciate them. > > wjr > > Tod E. Kurt wrote: >> This is the exact technique I use to let the user choose which serial >> port to use on startup. ?Here's a method I've got in many of my sketches: >> >> void choosePort() { >> ? String portlist[] = Serial.list(); >> ? String port = null; >> ? javax.swing.SwingUtilities.invokeLater(new Runnable() { >> ? ? public void run() { >> ? ? ? try { >> ? ? ? ? String port = (String) javax.swing.JOptionPane.showInputDialog( >> null, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Select Serial Port", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "MySuperSketch", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? javax.swing.JOptionPane.QUESTION_MESSAGE, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? null, portlist, null); >> ? ? ? ? if( port == null ) ?{ >> ? ? ? ? ? javax.swing.JOptionPane.showMessageDialog(null, "No port >> chosen, goodbye"); >> ? ? ? ? ? System.exit(1); >> ? ? ? ? } >> ? ? ? ? serialPort = port; >> ? ? ? } >> ? ? ? catch (Exception e) { >> ? ? ? ? e.printStackTrace(); >> ? ? ? } >> ? ? } >> ? } ); >> } >> >> >> On May 8, 2009, at 2:08 p, Brian Schlining wrote: >> >>> Bob's probably right...take look at javax.swing.SwingUtilites for the >>> workaround to get your swing stuff invoked on the EventDispatchThread >>> (EDT). Some swing-methods do work when called outside of the EDT, but >>> just to be safe, do your creation and swing calls on the EDT. It's >>> really simple, here's an example of a synchronous call. >>> >>> // Here's how to run stuff on the EDT from a different thread >>> SwingUtilities.invokeAndWait(new Runnable() { >>> ? ? ? public void run() { >>> ? ? ? ? ? ?JFileChooser fc; // create, setup, show your filechooser >>> ? ? ? ? ? ?// Get the result from the filechooser >>> ? ? ? } >>> }); >>> >>> To do a asynchronous call use SwingUtilities.invokeLater >>> >>> >>> >I wrote a small swing app to download images from an industrial camera. >>> >I used the two way serial sample code as a starting point. The app works >>> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >>> >then try to change the output directory or log file, the jfilechooser >>> >winds up trying to unpark (note, parking is not something I'm really >>> >familiar with) and doesn't. >>> What is the threading structure of your code? >>> >>> The various high-function Swing components, such as JFileChooser, are >>> notorious for doing Really Bad Stuff when invoked from off the Swing >>> thread. >>> >>> Bob >>> -- >>> Bob Jacobsen, UC Berkeley >>> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >>> JacobsenRG >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >>> -- >>> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >>> Brian Schlining >>> bschlining at gmail.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From cowwoc at bbs.darktech.org Fri May 15 07:18:29 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 09:18:29 -0400 Subject: [Rxtx] InputStream timeouts Message-ID: <4A0D6BA5.8020209@bbs.darktech.org> Why does InputStream.read() return -1 on timeout instead of throwing InterruptedIOException which has existed specifically for this purpose since JDK 1.0? Sockets throw SocketTimeoutException which extends InterruptedIOException. I suspect that this logic confuses BufferedInputStream as well as end-users. Can we introduce this change along with the other timeout-related changes? Gili From Steffen.DETTMER at ingenico.com Fri May 15 07:36:19 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 15 May 2009 15:36:19 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0D6BA5.8020209@bbs.darktech.org> References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <20090515133619.GC17036@elberon.bln.de.ingenico.com> * cowwoc wrote on Fri, May 15, 2009 at 09:18 -0400: > Why does InputStream.read() return -1 on timeout shouldn't it block and only avialable() should care about timeouts? That is how I understand `This method blocks until input data is available' from: http://java.sun.com/j2se/1.5.0/docs/api/java/io/InputStream.html#read() public abstract int read() throws IOException Reads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. A subclass must provide an implementation of this method. Returns: the next byte of data, or -1 if the end of the stream is reached. Throws: IOException - if an I/O error occurs. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Fri May 15 08:22:19 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 15 May 2009 17:22:19 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: >From the javadoc for InputStream: "If no byte is available because the end of the stream has been reached, the value -1 is returned." Since character timeout is not an indication of EOF condition I guess one could argue that 0 should be returned in case of timeout. On the other hand one could also argue that since no data was available (if it timed out) the serial port input stream was at the end of stream (albeit possibly temporarily only). Further the javadoc seems to forbid the return value 0 for Inputstream.read(): " This method blocks until input data is available, the end of the stream is detected, or an exception is thrown." So it can return n >= 1 , -1 or throw an exception. InputStream.read(byte[]) can return 0 but for consistency the options with the other read methods the return value for timeout needs to be -1 or an exception. It goes against my grain to think that I get an exception when I've set up a timeout and I am thus expecting a timeout to happen sometimes. So it is not an exceptional case but expected situation in which case a special return value is philosophically speaking more appropriate. So I'm against changing this behavior. I expect a lot of code depend on the -1 or at least on not getting an exception when a timeout occurs. In any case if an exception were to be thrown it should *not* be InterruptedIOException. >From the javadoc for InterruptedIOException: "An InterruptedIOException is thrown to indicate that an input or output transfer has been terminated because the thread performing it was interrupted. The field bytesTransferred indicates how many bytes were successfully transferred before the interruption occurred" I do not think this matches the case for serial port receive character timeout. I read the javadoc above so that I get this exception when the thread in my code that is performing a read or write operation gets interrupted by Thread.interrupt(). And this is used to handle exactly that case: being able to gracefully and cleanly interrupt threads. my 2 snt worth br Kusti > From: cowwoc > Date: Fri, 15 May 2009 16:18:29 +0300 > To: rxtx > Conversation: [Rxtx] InputStream timeouts > Subject: [Rxtx] InputStream timeouts > > > > Why does InputStream.read() return -1 on timeout instead of > throwing InterruptedIOException which has existed specifically for this > purpose since JDK 1.0? Sockets throw SocketTimeoutException which > extends InterruptedIOException. I suspect that this logic confuses > BufferedInputStream as well as end-users. Can we introduce this change > along with the other timeout-related changes? > > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From cowwoc at bbs.darktech.org Fri May 15 08:35:27 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 10:35:27 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <4A0D7DAF.5030705@bbs.darktech.org> I disagree with your interpretation. Read SocketTimeoutException to see what I mean. InterruptedIOException means the operation was interrupted, not necessarily by way of Thread.interrupt(). Returning 0 in case of timeout sounds wrong to me because it is a legal byte value that could have been read. Returning -1 also sounds wrong to me because this isn't strictly the end of stream. BufferedInputStream and others assume that once you reach the end of stream you will never see more data, ever. As far as I know, the core APIs are written in terms of throwing InterruptedIOException for timeouts. Gili Kustaa Nyholm wrote: > >>From the javadoc for InputStream: > > "If no byte is available because the end of the stream has been reached, the > value -1 is returned." > > > Since character timeout is not an indication of EOF condition I guess one > could argue that 0 should be returned in case of timeout. On the other hand > one could also argue that since no data was available (if it timed out) the > serial port input stream was at the end of stream (albeit possibly > temporarily only). Further the javadoc seems to forbid the return value 0 > for Inputstream.read(): > > " This method blocks until input data is available, the end of the stream is > detected, or an exception is thrown." > > So it can return n >= 1 , -1 or throw an exception. InputStream.read(byte[]) > can return 0 but for consistency the options with the other read methods the > return value for timeout needs to be -1 or an exception. > > It goes against my grain to think that I get an exception when I've set up a > timeout and I am thus expecting a timeout to happen sometimes. So it is not > an exceptional case but expected situation in which case a special return > value is philosophically speaking more appropriate. > > So I'm against changing this behavior. I expect a lot of code depend on the > -1 or at least on not getting an exception when a timeout occurs. > > In any case if an exception were to be thrown it should *not* be > InterruptedIOException. > >>From the javadoc for InterruptedIOException: > > > "An InterruptedIOException is thrown to indicate that an input or output > transfer has been terminated because the thread performing it was > interrupted. The field bytesTransferred indicates how many bytes were > successfully transferred before the interruption occurred" > > I do not think this matches the case for serial port receive character > timeout. I read the javadoc above so that I get this exception when the > thread in my code that is performing a read or write operation gets > interrupted by Thread.interrupt(). And this is used to handle exactly that > case: being able to gracefully and cleanly interrupt threads. > > > > my 2 snt worth br Kusti > > > > >> From: cowwoc >> Date: Fri, 15 May 2009 16:18:29 +0300 >> To: rxtx >> Conversation: [Rxtx] InputStream timeouts >> Subject: [Rxtx] InputStream timeouts >> >> >> >> Why does InputStream.read() return -1 on timeout instead of >> throwing InterruptedIOException which has existed specifically for this >> purpose since JDK 1.0? Sockets throw SocketTimeoutException which >> extends InterruptedIOException. I suspect that this logic confuses >> BufferedInputStream as well as end-users. Can we introduce this change >> along with the other timeout-related changes? >> >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From m.j.tandy at warwick.ac.uk Fri May 15 09:17:36 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Fri, 15 May 2009 16:17:36 +0100 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <302aa0340905150817o39812d7y1b896004a2dcc2ab@mail.gmail.com> > I disagree with your interpretation. Read SocketTimeoutException to see > what I mean. InterruptedIOException means the operation was interrupted, > not necessarily by way of Thread.interrupt(). Strangely enough, the javadoc for InterruptedIOException says: "An InterruptedIOException is thrown to indicate that an input or output transfer has been terminated because the thread performing it was interrupted."[1] But the subclass SocketTimeoutException is used differently - here's an example from sun.net.httpserver.request: /** * block() only called when available==0 and buf is empty */ private synchronized void block () throws IOException { long currtime = server.getTime(); long maxtime = currtime + readTimeout; while (currtime < maxtime) { if (selector.select (readTimeout) == 1) { selector.selectedKeys().clear(); available (); return; } currtime = server.getTime(); } throw new SocketTimeoutException ("no data received"); } So it seems that SocketTimeoutExceptions get thrown not upon thread interruptions, but a certain time after a blocking read is started. [1] http://java.sun.com/javase/6/docs/api/java/io/InterruptedIOException.html From cowwoc at bbs.darktech.org Fri May 15 11:06:53 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 13:06:53 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0DA0F4.9050203@bbs.darktech.org> References: <4A0DA0F4.9050203@bbs.darktech.org> Message-ID: <4A0DA12D.2050303@bbs.darktech.org> Forgot to CC the list. Gili cowwoc wrote: > > "Thread was interrupted" does not necessarily mean > Thread.interrupt(). It just means that the operation (run by the thread) > was interrupted. If you read the beginning sentence for > InterruptedIOException it reads "Signals that an I/O operation has been > interrupted". This says nothing about the thread itself. Michael's > subsequent post about SocketTimeoutException reinforces that point. > > By the way, I think that in general you need to interpret the > Javadoc for core classes in a broader sense than it seems. Older Javadoc > (from version 1.0) used to mention implementation details that were not > necessarily important and limited the applicability of the classes. > Newer documentation tends to go out of its way to avoid mentioning such > implementation detail and I believe that's a good thing. When > InterruptedIOException was written, Thread.interrupt() was probably the > only way to interrupt I/O operations. Nowadays there are others. Sun has > generalized its meaning over time as evident by SocketTimeoutException. > At least, that's my interpretation :) > > Gili > > Kustaa Nyholm wrote: >>> I disagree with your interpretation. Read >>> SocketTimeoutException to >>> see >>> what I mean. InterruptedIOException means the operation was interrupted, >>> not necessarily by way of Thread.interrupt(). >> >> Well SocketTimeoutException javadoc only says, very briefly: >> >> "Signals that a timeout has occurred on a socket read or accept." >> >> So that is not too helpful. But since it is derived from >> InterruptedIOException my interpretation it that they have an 'is-a' >> relationship and InterruptedIOException needs to honor the contract of >> InterruptedIOException which says: >> >> "...because the thread performing it was interrupted." >> >> To me this very specifically talks about interrupting threads with >> Thread.interrupt() >> >> >>> Returning 0 in case of timeout sounds wrong to me because it >>> is a >>> legal >>> byte value that could have been read. >> Agreed, that's what I tried to say. 0 is a legal byte value for read() to >> return so that cannot be used. For read read(byte[]) which returns the >> number of bytes read 0 could be used but there again 0 can be returned >> if 0 >> byte[] size is 0. So there again 0 is not a good option. >> >>> Returning -1 also sounds wrong to >>> me because this isn't strictly the end of stream. >> Like I said, it isn't strictly the end of stream. But also does not >> forbid treating it as (temporary) end of stream. >> >>> BufferedInputStream >>> and others assume that once you reach the end of stream you will never >>> see more data, ever. >> Can you provide a reference for that. >> >>> As far as I know, the core APIs are written in >>> terms of throwing InterruptedIOException for timeouts. >> Would also like to see something to support that. >> >> >> The behavior of throwing an exception on timeout is also a little bit >> problematic, consider: >> >> byte buf[1000]; >> int n=ins.read(buf); >> // do something with the n bytes received >> >> What happens if a timeout occurs before we have received 1000 bytes? >> >> If an exception is thrown then the user of the read() needs to handle >> the bytes received in two places or else those last <1000 bytes are lost. >> A better solution would be to return the bytes received so far and throw >> the exception on the next call (if any). But the main point is that >> neither of these case obviously correct and neither is specified in the >> javadocs. Where as a lot of code that just handles the return value >> of read(byte[]) correctly works without any further ado. >> >> >> >> The main thing is that I think we should not break existing applications, >> which I expect are not handling InterruptedIOException but many of >> which may >> depend on getting back -1 in case of timeouts. >> >> It has been a while since I used the javax.javacomm but I seem to recall >> that it returned -1 and I think this is the defining standard. >> >> I expect most rxtx users are more interested in compatibility and >> stability >> than semantic niceties and improving the API. >> >> br Kusti >> >> >> > From johnny.luong at trustcommerce.com Fri May 15 13:16:15 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Fri, 15 May 2009 12:16:15 -0700 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0DA12D.2050303@bbs.darktech.org> References: <4A0DA0F4.9050203@bbs.darktech.org> <4A0DA12D.2050303@bbs.darktech.org> Message-ID: <4A0DBF7F.50808@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 cowwoc wrote: | Forgot to CC the list. | | Gili | | cowwoc wrote: |> "Thread was interrupted" does not necessarily mean |> Thread.interrupt(). It just means that the operation (run by the thread) |> was interrupted. If you read the beginning sentence for |> InterruptedIOException it reads "Signals that an I/O operation has been |> interrupted". This says nothing about the thread itself. Michael's |> subsequent post about SocketTimeoutException reinforces that point. |> |> By the way, I think that in general you need to interpret the |> Javadoc for core classes in a broader sense than it seems. Older Javadoc |> (from version 1.0) used to mention implementation details that were not |> necessarily important and limited the applicability of the classes. |> Newer documentation tends to go out of its way to avoid mentioning such |> implementation detail and I believe that's a good thing. When |> InterruptedIOException was written, Thread.interrupt() was probably the |> only way to interrupt I/O operations. Nowadays there are others. Sun has |> generalized its meaning over time as evident by SocketTimeoutException. |> At least, that's my interpretation :) |> |> Gili |> |> Kustaa Nyholm wrote: |>>> I disagree with your interpretation. Read |>>> SocketTimeoutException to |>>> see |>>> what I mean. InterruptedIOException means the operation was interrupted, |>>> not necessarily by way of Thread.interrupt(). |>> Well SocketTimeoutException javadoc only says, very briefly: |>> |>> "Signals that a timeout has occurred on a socket read or accept." |>> |>> So that is not too helpful. But since it is derived from |>> InterruptedIOException my interpretation it that they have an 'is-a' |>> relationship and InterruptedIOException needs to honor the contract of |>> InterruptedIOException which says: |>> |>> "...because the thread performing it was interrupted." |>> |>> To me this very specifically talks about interrupting threads with |>> Thread.interrupt() |>> |>> |>>> Returning 0 in case of timeout sounds wrong to me because it |>>> is a |>>> legal |>>> byte value that could have been read. |>> Agreed, that's what I tried to say. 0 is a legal byte value for read() to |>> return so that cannot be used. For read read(byte[]) which returns the |>> number of bytes read 0 could be used but there again 0 can be returned |>> if 0 |>> byte[] size is 0. So there again 0 is not a good option. |>> |>>> Returning -1 also sounds wrong to |>>> me because this isn't strictly the end of stream. |>> Like I said, it isn't strictly the end of stream. But also does not |>> forbid treating it as (temporary) end of stream. |>> |>>> BufferedInputStream |>>> and others assume that once you reach the end of stream you will never |>>> see more data, ever. |>> Can you provide a reference for that. |>> |>>> As far as I know, the core APIs are written in |>>> terms of throwing InterruptedIOException for timeouts. |>> Would also like to see something to support that. |>> |>> |>> The behavior of throwing an exception on timeout is also a little bit |>> problematic, consider: |>> |>> byte buf[1000]; |>> int n=ins.read(buf); |>> // do something with the n bytes received |>> |>> What happens if a timeout occurs before we have received 1000 bytes? |>> |>> If an exception is thrown then the user of the read() needs to handle |>> the bytes received in two places or else those last <1000 bytes are lost. |>> A better solution would be to return the bytes received so far and throw |>> the exception on the next call (if any). But the main point is that |>> neither of these case obviously correct and neither is specified in the |>> javadocs. Where as a lot of code that just handles the return value |>> of read(byte[]) correctly works without any further ado. |>> |>> |>> |>> The main thing is that I think we should not break existing applications, |>> which I expect are not handling InterruptedIOException but many of |>> which may |>> depend on getting back -1 in case of timeouts. |>> |>> It has been a while since I used the javax.javacomm but I seem to recall |>> that it returned -1 and I think this is the defining standard. |>> |>> I expect most rxtx users are more interested in compatibility and |>> stability |>> than semantic niceties and improving the API. |>> |>> br Kusti |>> |>> |>> | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi, Maybe a better approach (improving the API) would be to consider implementing a NIO interface atop the underlying serial communication... ~ if someone desires the existing behavior, then they use a facade that lies atop of the NIO and provide the same quirks associated with it. As I see it, the implementation overrides the general contract of the InputStream to provide for the timeout functionality and it would be somewhat troublesome to expect a user of that API to catch subclasses of IOException. Best, Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoNv38ACgkQnQTBLXttTeWZ+wCeO4CTrI5l+vLPrjHl8fBj7FOL Ft8AnjQ7bXnvMhOlwZdK5CYAuoQeQ9u0 =QAax -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon May 18 03:49:50 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 11:49:50 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <20090518094950.GG17036@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, May 15, 2009 at 17:22 +0300: > >From the javadoc for InputStream: > > Since character timeout is not an indication of EOF condition I > guess one could argue that 0 should be returned in case of > timeout. A blocking operation logically has no timeout. It is blocking. Forever, until EOF or an error. This IMHO renders usage of read() useless and read(byte[]) must be used (or no InputStream). > On the other hand one could also argue that since no data was > available (if it timed out) IMHO, read() must not time out. What would happen with a small simple console app that is relying that InputStream is implemented as required by specification? It cannot tell `no byte was received but this is not an error, please call me again' - and why should it? I think, if this is not suited, i.e. if the application may want a byte but also may not want a byte, no blocking function must be invoked, but a select must be called instead or, if no select-style function is avialable, polling must be used. This is the InputStream way (block or poll). For streams the `may or may not want a byte' may sound unlikely, but in practice this is what happens, for instance, if there is some CANCEL button in a GUI or so. Closing the stream often also is no option because it cannot be reopend but it might be needed again later. In classic unix apps often signals were used (read(2) can return EINTR), but in Java this isn't possible AFAIK. EINTR IMHO has not much relation to InterruptedIOException and I think InterruptedIOException cannot be `enforced' without doing harm. > It goes against my grain to think that I get an exception when > I've set up a timeout yeah, I thought the same and when I hit this InputStream the first time I though: ohh, a bug. Or a bunch of :-) As specified, InputStream has no timeout. If you set a timeout, then somewhere else (e.g. a sub class). In this case, the sub class should also offer a way to wait for this timeout (e.g. a select style function). In practice, this makes not much sense, leaving the options not to use it at all (but what else then?) or to violate the specification. Unfortunately it seems that subclasses add setTimeout but no select() or tryRead() or simply a available()-style with a timeout parameter. Then applications would simply use this subclasses. In practice, then it does not help that they derive InputStream at all, so personally I think they should not derive from it but instead define something with a meaning :-) But I think in practice, for read(byte[]) returning 0 (e.g. in case of [intercharacter] timeout) for many people seems straightforward - so this is probably what most people will expect. (an interesting question is how those bugs happend to the Java guys, because those topics are well known since ages and solved, for instance, in the BSD socket API, but probably they didn't know it. It took years but now it seems they understood and tried it again by some NIO which is more in the `usual way'. Next version might be usable - I wouldn't be surprised if this one then is BSD socket API alike :-) SCNR). So in practice I think: - don't use read() but read(byte[]) or read(byte[], int, int) - handle `0 bytes read' situation - polling avialable() in practice may often not be suited because avialable() has no timeout parameter and if response time is important, small polling intervals would be needed which generate load - try to avoid using InputStream (from applications) directly because it sucks and it is /not/ generic (implementations may interpret it differently because it MUST be interpreted because the specification makes not much sense in many cases) - IOException and InterruptedIOException are for I/O error situations. Additionally I think, InterruptedIOException.bytesTransferred cannot be reliable because there are cases where the OS cannot surely know this and thus cannot tell it the JVM also, peer may have not received them even if they were sent As far as I know this is exactly what rxtx is doing. When having many clients this require many threads and might be less performant, so best is not to have one thousand serial ports :-) Returning 0 here IMHO also is the only option that does not `directly' violate the spec. It tells `there is an attempt to read at least one byte.' so someone could argue that the dear computer `attempted but found no time to do so' :-) > So I'm against changing this behavior. I expect a lot of code > depend on the -1 or at least on not getting an exception when a > timeout occurs. Yes, I agree, -1 means End of file (or closed by peer) and exceptions are for errors. If exceptions should be added I think it could be made configurable. For instance by some Rs232InputStream.enableException(IOException e), store this exception and later if (e != null) throw e.clone() or so. > I do not think this matches the case for serial port receive character > timeout. I read the javadoc above so that I get this exception when the > thread in my code that is performing a read or write operation gets > interrupted by Thread.interrupt(). And this is used to handle exactly that > case: being able to gracefully and cleanly interrupt threads. (well, I think Thread.interrupt() also is a big topic on its own and I'm afraid there is no really reliable mechanism for `cleanly interrupt threads' and maybe even that logically threads cannot be interrupted cleanly at all) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From rxtx at qbang.org Mon May 18 05:17:08 2009 From: rxtx at qbang.org (VIAGRA ® Official Site) Date: Mon, 18 May 2009 05:17:08 -0600 Subject: [Rxtx] DISCOUNT ID42992 75% 0FF on Pfizer ! Message-ID: <200905181117.n4IBH8ku024296@rxtx.qbang.org> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/4c172d08/attachment-0004.html From Kustaa.Nyholm at planmeca.com Mon May 18 07:20:40 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 18 May 2009 16:20:40 +0300 Subject: [Rxtx] InputStream timeouts Message-ID: Oops, sorry sent this to Steffen directly instead of mailing list. So here for the list: > A blocking operation logically has no timeout. It is blocking. > Forever, until EOF or an error. This IMHO renders usage of read() > useless and read(byte[]) must be used (or no InputStream). This is true, however read(byte[]) too is blocking so logically that (allowing it to return with value 0 in case of timeout) is no better (or worse) than read(). According to InputsStream javadoc only when byte[].length is 0 is read(byte[]) non blocking and can return 0. But to be clear: I'm in favor of returning 0 in case of timeouts for read(byte[]) and -1 for read(). > >> On the other hand one could also argue that since no data was >> available (if it timed out) > > IMHO, read() must not time out. IMHO read() should behave consistently with respect to the other read(...) methods. If we allow them to timeout, we should also allow read() to timeout. And in that case we need a return value that separates that case from normal return value (0-255), so -1 seems like a good candidate. > What would happen with a small > simple console app that is relying that InputStream is > implemented as required by specification? It cannot tell `no byte > was received but this is not an error, please call me again' > - and why should it? I think that the simple console app would be just fine, because timeouts are disabled by default so the simple applications are not affected. > > In practice, this makes not much sense, leaving the options not > to use it at all (but what else then?) or to violate the > specification. The javadoc for CommPort.getInputStream() spells out the rules for timeouts: http://java.sun.com/products/javacomm/reference/api/javax/comm/CommPort.html #getInputStream() So, IMO, while it is interesting to discuss these things the javacomm specs is quite clear about blocking behavior and although there is some conflict between how (file) inputstream behaves and Commport inputstreams behave, I think rxtx should adhere to the javacomm spec. > But I think in practice, for read(byte[]) returning 0 (e.g. in > case of [intercharacter] timeout) for many people > seems straightforward - so this is probably what most people will > expect. Agreed, I'm 100% sure there are lots of people out there that use timeouts and depend on the current behavior. Changing this would not help them but infuriate them. > > (well, I think Thread.interrupt() also is a big topic on its own > and I'm afraid there is no really reliable mechanism for > `cleanly interrupt threads' and maybe even that logically > threads cannot be interrupted cleanly at all) Would be interesting to discuss that too but that is beyond the topic of this thread. However I still believe that the InterruptedIOException was introduced so that blocking IO calls could gracefully 'return' if the calling thread was interrupted. Weather this is reliable or clean or graceful could be discussed but to me it seem reasonable. If you have a thread that is blocking on some I/O we need a mechanism that allows stopping that thread in a controlled manner and InterruptedIOException seems to provide this. cheers Kusti From Steffen.DETTMER at ingenico.com Mon May 18 09:18:37 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 17:18:37 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <20090518151837.GS17036@elberon.bln.de.ingenico.com> [OT] * Kustaa Nyholm wrote on Mon, May 18, 2009 at 16:20 +0300: > > A blocking operation logically has no timeout. It is blocking. > > Forever, until EOF or an error. This IMHO renders usage of read() > > useless and read(byte[]) must be used (or no InputStream). > This is true, however read(byte[]) too is blocking so logically that > (allowing it to return with value 0 in case of timeout) is no better > (or worse) than read(). According to InputsStream javadoc only when > byte[].length is 0 is read(byte[]) non blocking and can return 0. I think the essential difference is that for read(byte[]) returning 0 is somewhat clear, but for read() 0 is a valid byte and thus it would be a horrible mess to also use it for timeouts :) > >> On the other hand one could also argue that since no data was > >> available (if it timed out) > > > > IMHO, read() must not time out. > > IMHO read() should behave consistently with respect to the > other read(...) methods. If we allow them to timeout, we should > also allow read() to timeout. And in that case we need a return > value that separates that case from normal return value (0-255), > so -1 seems like a good candidate. Well, but then this is not consistently to EOF handling... (and if read() cannot be consistent, maybe not using it at all is an option?) > > What would happen with a small simple console app that is > > relying that InputStream is implemented as required by > > specification? It cannot tell `no byte was received but this > > is not an error, please call me again' - and why should it? > I think that the simple console app would be just fine, because > timeouts are disabled by default so the simple applications are > not affected. Not setting timeouts IMHO does not mean no timeouts will be applied but that some default timeout is used instead, which could be infinite or some OS value, which in turn may be configurable (like the TCP wait timeouts). > > In practice, this makes not much sense, leaving the options not > > to use it at all (but what else then?) or to violate the > > specification. > > The javadoc for CommPort.getInputStream() spells out the rules for > timeouts: > > http://java.sun.com/products/javacomm/reference/api/javax/comm/CommPort.html > #getInputStream() > So, IMO, while it is interesting to discuss these things > the javacomm specs is quite clear about blocking behavior > and although there is some conflict between how (file) inputstream > behaves and Commport inputstreams behave, I think rxtx should > adhere to the javacomm spec. I think first this does not clearly state what happens a read caller when a timeout occures and second IMHO it does violate the InputStream specification contract (API/javadoc). Formally speaking, it is a bug :-) Also those `advisory methods' in a formal interface are bad, I think. But another topic and discussed already several times :) Yes, in the end it seems the clear correct possiblity (no timeouts) makes no sense, so something pragmatic is needed :-) > > But I think in practice, for read(byte[]) returning 0 (e.g. in > > case of [intercharacter] timeout) for many people > > seems straightforward - so this is probably what most people will > > expect. > Agreed, I'm 100% sure there are lots of people out there that > use timeouts and depend on the current behavior. Changing this > would not help them but infuriate them. yeah, and when shifting to another type of InputStream suddenly they may break, rendering that interface a bit useless, but this is all we have... Correct IMHO would be that the compiler is able to check whether an interface supports timeouts or not (i.e. all methods exist and work as specified or a different interface must be used. Lets say we would have InputStream and InputStreamTimeout or whatever, there would be so many possibilities, but most with own disadvantages). Well, I wonder why they did not even add a timeout parameter to available() and why they forgot about write timeouts completely (also there is no counterpart to available()). Anyway. > > (well, I think Thread.interrupt() also is a big topic on its own > > and I'm afraid there is no really reliable mechanism for > > `cleanly interrupt threads' and maybe even that logically > > threads cannot be interrupted cleanly at all) > Would be interesting to discuss that too but that is beyond the > topic of this thread. However I still believe that the > InterruptedIOException was introduced so that blocking > IO calls could gracefully 'return' if the calling thread > was interrupted. Yes, maybe they forgot it in first place, then found that read can throw IOExceptions only and thus invented InterruptedIOException for InterruptedException-alike cases? but anyway. > Weather this is reliable or clean or graceful could be > discussed but to me it seem reasonable. (With not reliable I mean, when for instance you wanted to write 10 byte and you get this exception telling 5 byte have been written, you cannot be sure what this means. Maybe the 6th byte is in a fifo or whatever. I think best is to avoid the need to handle this). > If you have a thread that is blocking on some I/O we need a > mechanism that allows stopping that thread in a controlled > manner and InterruptedIOException seems to provide this. I think also this is not reliable, because even if the JVM knows a thread is supposed to be `killed', I see at least two issues: first is that native code may be active and cannot be forced to return and second it could be that the thread would need to perform clean up tasks, and since Java does not support RAII (destructors cannot clean), at least you get in trouble when exceptions happening during this cleanup (i.e. exceptions after the thread stops). This in turn IMHO is likely to happen because a well-known situation to interrupt such a thread might be after some error, and after errors exceptions I think happen more often (because less well tested and others). Let's say the thread uses an InputStream (owned by someone else) and now discards it by calling it's close (which should be a delete - because what is an input stream which is closed? Obviously it is not an input stream anymore :-)). Now you might have a special InputStream requiring special things (it might be a protocol requiring some final quit message to be sent, it might need not to close it if used by someone else, too, additional actions may be needed). Logically this could be implemented (turing complete language :-)), but in practice it might not be possible, simply because too complex (to do it right in all circumstances). oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Mon May 18 10:02:39 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 18 May 2009 19:02:39 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: > Not setting timeouts IMHO does not mean no timeouts will be > applied but that some default timeout is used instead, which > could be infinite or some OS value, which in turn may be > configurable (like the TCP wait timeouts). > The javadoc says: "By default, receive timeout is not enabled." and "By default, receive threshold is not enabled." thus (from getInputStream javadoc): "block until any data is available" which is consistent InputStream contract. > I think first this does not clearly state what happens a read > caller when a timeout occures That is true. > and second IMHO it does violate the > InputStream specification contract (API/javadoc). Formally > speaking, it is a bug :-) Agreed, but I think given the advantages you get by using InputStream (as means of reading the serial port as opposed to coming up with some totally new Stream concept) I think this was reasonable compromise and bending of the rules. > yeah, and when shifting to another type of InputStream suddenly > they may break, rendering that interface a bit useless, but this > is all we have... Exactly. > (With not reliable I mean, when for instance you wanted to write > 10 byte and you get this exception telling 5 byte have been > written, you cannot be sure what this means. Maybe the 6th byte > is in a fifo or whatever. I think best is to avoid the need to > handle this). I think all we can assume is that at least 5 bytes have been written into the native driver, weather they are in the fifo or whatever we cannot know. But as you wrote, best avoid depending on this behaviour. > I think also this is not reliable, because even if the JVM knows > a thread is supposed to be `killed', I see at least two issues: > first is that native code may be active and cannot be forced to > return Yes, but this is sort of implementation detail, not an API or Java design issue. The JVM and system class implementations should guarantee this (I bet they don't, consistently, for all platforms and OSes). > and second it could be that the thread would need to > perform clean up tasks, and since Java does not support RAII > (destructors cannot clean), at least you get in trouble when > exceptions happening during this cleanup (i.e. exceptions after > the thread stops). I sort of see what you mean, but still I do not see how this could happen if the cleanup catches exceptions properly. But then I've not studied this in detail. > This in turn IMHO is likely to happen because > a well-known situation to interrupt such a thread might be after > some error, and after errors exceptions I think happen more often > (because less well tested and others). > > Let's say the thread uses an InputStream (owned by someone else) > and now discards it by calling it's close (which should be a > delete - because what is an input stream which is closed? > Obviously it is not an input stream anymore :-)). > Now you might have a special InputStream requiring special things > (it might be a protocol requiring some final quit message to be > sent, it might need not to close it if used by someone else, > too, additional actions may be needed). > Logically this could be implemented (turing complete language :-)), > but in practice it might not be possible, simply because too > complex (to do it right in all circumstances). Ok, I think I understand what you mean: you are saying that what mention aboce "if the cleanup catches exceptions properly" maybe be and often is too difficult/complex to implement and test properly? Yeah, seen that, been there, fallen for it... cheers Kusti From Steffen.DETTMER at ingenico.com Mon May 18 10:39:26 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 18:39:26 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: <20090518163925.GV17036@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Mon, May 18, 2009 at 19:02 +0300: > > Not setting timeouts IMHO does not mean no timeouts will be > > applied but that some default timeout is used instead, which > > could be infinite or some OS value, which in turn may be > > configurable (like the TCP wait timeouts). > > > The javadoc says: > "By default, receive timeout is not enabled." > and > "By default, receive threshold is not enabled." mmm... but they are optional, so what if a driver does not support timeouts but underlaying comm interface does? anyway, *I* would not rely (but loop) but maybe this is not needed. > > and second IMHO it does violate the > > InputStream specification contract (API/javadoc). Formally > > speaking, it is a bug :-) > Agreed, but I think given the advantages you get by using > InputStream (as means of reading the serial port as opposed > to coming up with some totally new Stream concept) I think > this was reasonable compromise and bending of the rules. I don't like InputStream at all. I think it is not an abstraction to remove and later re-add (hack in) needing things. I dislike that noone knows whether it streams bytes or chars or unicode or whatever. Also, I'm used birectional things (`all things are files') for communications, I think it is simpler. So InputStream IMHO is oversimplified. Maybe it was inspired by unix line discipline (but you can select it :-)). Who knows. Anyway. > > I think also this is not reliable, because even if the JVM knows > > a thread is supposed to be `killed', I see at least two issues: > > first is that native code may be active and cannot be forced to > > return > Yes, but this is sort of implementation detail, not an API or > Java design issue. The JVM and system class implementations should > guarantee this (I bet they don't, consistently, for all platforms > and OSes). I think when no reasonable implementation is possible, probably the design is not good. If there is no reasonable way to shutdown (kill) a thread (which is the case IMHO), it makes not much sense to design it. Instead, some mechanism would be needed. I guess the InterruptedException in fact is such a kind of mechanism. I'm not sure but I think Java itself disencourages to use it. > > and second it could be that the thread would need to > > perform clean up tasks, and since Java does not support RAII > > (destructors cannot clean), at least you get in trouble when > > exceptions happening during this cleanup (i.e. exceptions after > > the thread stops). > I sort of see what you mean, but still I do not see how this > could happen if the cleanup catches exceptions properly. But > then I've not studied this in detail. > Ok, I think I understand what you mean: you are saying that > what mention aboce "if the cleanup catches exceptions properly" > maybe be and often is too difficult/complex to implement and > test properly? Yes, since it should work for any implementation, it should work for InputStreams that call abitrary complex read operations. I have applications where the read leads to some CORBA calls to a remote C++ application which also has its complexity. Now in some finally {} exceptions can occure, for instance during member destruction (closing). For example, if you have a facade like implementation with: { old = setMyLogLevel(off); for (i=0; i Yeah, seen that, been there, fallen for it... (welcome in the club :-)) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bill7007 at gmail.com Mon May 18 11:08:45 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 18 May 2009 13:08:45 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090518151837.GS17036@elberon.bln.de.ingenico.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: I can add this thought, I think the timeout is part of a protocol, which should sit above RXTX. The main feature needed in RXTX to support a protocol using timeouts is a way to interrupt it into a known state, like a reset() function. The function should cause an exception to any associated thread that was waiting on IO, maybe a unique exception due to reset() call. An IO (as opposed to Interrupted) exception may be better since the reset() has to leave a known state which may affect IO in progress. I helped work a similar situation in a CAN bus protocol. In the protocol, a send would be followed by a wait for receive. A timeout thread was enabled which caused an "alarm" event to any registered handlers upon timeout. A receive canceled the timeout alarm. The timing and thread coordination is tricky but that is all left to the protocol code. The protocols timeout event handler reset the CAN controller to get it into a known state for a retry. The reset caused an IO exception to the waiting read thread which could check that a timeout had caused it. So, if timeout is considered part of a higher level protocol class, read and write don't need special interface features as long as there is a way for a waiting state in native code to be forced to exit in a reliable, detectable, manner. +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/c9b25045/attachment-0003.html From johnny.luong at trustcommerce.com Mon May 18 11:49:53 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 18 May 2009 10:49:53 -0700 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: <4A119FC1.3090700@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Johnson wrote: | I can add this thought, I think the timeout is part of a protocol, which | should sit above RXTX. The main feature needed in RXTX to support a protocol | using timeouts is a way to interrupt it into a known state, like a reset() | function. The function should cause an exception to any associated thread | that was waiting on IO, maybe a unique exception due to reset() call. An IO | (as opposed to Interrupted) exception may be better since the reset() has to | leave a known state which may affect IO in progress. | | I helped work a similar situation in a CAN bus protocol. In the protocol, a | send would be followed by a wait for receive. A timeout thread was enabled | which caused an "alarm" event to any registered handlers upon timeout. A | receive canceled the timeout alarm. The timing and thread coordination is | tricky but that is all left to the protocol code. The protocols timeout | event handler reset the CAN controller to get it into a known state for a | retry. The reset caused an IO exception to the waiting read thread which | could check that a timeout had caused it. | | So, if timeout is considered part of a higher level protocol class, read and | write don't need special interface features as long as there is a way for a | waiting state in native code to be forced to exit in a reliable, detectable, | manner. | | +BillJ | | | | ------------------------------------------------------------------------ | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx Hi Bill, This is all conjecture and probably a lot of work in practice, so its just a train of thought at this point (via NIO)... Supposer SerialPort were to implement a method that returned "SerialPortChannel" which worked along similar lines as a SocketChannel. ~ Then you could in practice, have a Selector object that did the timeout you described above (via a register method)... your read and write methods could block or not block and it would be a lot easier to drive multiple serial ports than what you have today. - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoRn8EACgkQnQTBLXttTeXm0gCfaua0ej3Rt0fogRR68bbEFG0Z BTwAn1s79U8ZU0yj6xcND8gyHzDmKKqq =ThWj -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon May 18 11:54:10 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 19:54:10 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: <20090518175409.GW17036@elberon.bln.de.ingenico.com> (OT) * Bill Johnson wrote on Mon, May 18, 2009 at 13:08 -0400: > I can add this thought, I think the timeout is part of a > protocol, which should sit above RXTX. Probably actually on both levels timeouts can be helpful; if there is some PPP/TCP or other full duplex multiplexing protcol I think at least it is nice to be able to read with some reasonable timeout(s). > I helped work a similar situation in a CAN bus protocol. In the > protocol, a send would be followed by a wait for receive. A > timeout thread was enabled which caused an "alarm" event to > any registered handlers upon timeout. A receive canceled the > timeout alarm. The timing and thread coordination is tricky but > that is all left to the protocol code. (this Bosch car protocol?) But if the protocol implementation knows the timeout value, wouldn't it be easier and suited better to have some way to apply it to the reads without needing multithreading? Was the implementation in Java? How to cancel the receive by the timeout alarm? Was it (protocol thread implementation) internally polling? You said later, `a way for a waiting state in native code to be forced to exit in a reliable, detectable, manner'. Sounds complicated :) Is this a generic requirement? I think, protocols often can be implemented to use InputStream (or some other interface) but also to offer the same interface (like the decorator pattern). At least when `stacking' such protocols it can become quite difficult, even if having an own thread per protocol instance. Of course heavily depends on the project and situation. Well, interesting topic :) > The protocols timeout event handler reset the CAN controller to > get it into a known state for a retry. The reset caused an IO > exception to the waiting read thread which could check that a > timeout had caused it. Ohh, the CAN controller must be reset? Though they would handle a whole frame automatically. I have no clue about this; surely it is very specific and complex. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bill7007 at gmail.com Mon May 18 12:25:19 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 18 May 2009 14:25:19 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A119FC1.3090700@trustcommerce.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <4A119FC1.3090700@trustcommerce.com> Message-ID: Hi Johnny, I think a SerialPortChannel could be a good example. It uses an underlying Socket which uses an underlying implementation to support open, timeouts, etc. As part of the implementation is where the current RXTX could come in, provided there is a way to back out of a blocking situation. +BillJ On Mon, May 18, 2009 at 1:49 PM, Johnny Luong < johnny.luong at trustcommerce.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Bill Johnson wrote: > | I can add this thought, I think the timeout is part of a protocol, which > | should sit above RXTX. > ... > > Hi Bill, > > This is all conjecture and probably a lot of work in practice, so its > just a train of thought at this point (via NIO)... > > Supposer SerialPort were to implement a method that returned > "SerialPortChannel" which worked along similar lines as a SocketChannel. > ~ Then you could in practice, have a Selector object that did the timeout > you described above (via a register method)... your read and write > methods could block or not block and it would be a lot easier to drive > multiple serial ports than what you have today. > > - -Johnny > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkoRn8EACgkQnQTBLXttTeXm0gCfaua0ej3Rt0fogRR68bbEFG0Z > BTwAn1s79U8ZU0yj6xcND8gyHzDmKKqq > =ThWj > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/0a44a920/attachment-0003.html From lyon at docjava.com Mon May 18 13:18:53 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 18 May 2009 15:18:53 -0400 Subject: [Rxtx] image capture In-Reply-To: References: Message-ID: Hi All, I know this is off-topic, but we have so many native method interface experts here, I just had to ask; Is anyone able to do image capture on a 64 bit mac, using Java? QT4J is not loadable using Java 6 (AFAIK). Thanks! - Doug From bill7007 at gmail.com Mon May 18 13:24:04 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 18 May 2009 15:24:04 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090518175409.GW17036@elberon.bln.de.ingenico.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> Message-ID: On Mon, May 18, 2009 at 1:54 PM, Steffen DETTMER < Steffen.DETTMER at ingenico.com> wrote: > (OT) > > * Bill Johnson wrote on Mon, May 18, 2009 at 13:08 -0400: > > I can add this thought, I think the timeout is part of a > > protocol, which should sit above RXTX. > > Probably actually on both levels timeouts can be helpful; if > there is some PPP/TCP or other full duplex multiplexing protcol I > think at least it is nice to be able to read with some reasonable > timeout(s). I think timeout at the native level does not fit well with a read() concept of timeout because it depends on the protocol not really on the read(). > > > I helped work a similar situation in a CAN bus protocol. In the > > protocol, a send would be followed by a wait for receive. A > > timeout thread was enabled which caused an "alarm" event to > > any registered handlers upon timeout. A receive canceled the > > timeout alarm. The timing and thread coordination is tricky but > > that is all left to the protocol code. > > (this Bosch car protocol?) > > But if the protocol implementation knows the timeout value, > wouldn't it be easier and suited better to have some way to apply > it to the reads without needing multithreading? > If you are waiting on a read and you are waiting on a timeout at the same time, that is two logical threads. Maybe you are looping check for one of two condition, character or timeout, but I think its the same logically as waiting for a character or a timeout exception. It is a special case where you try to read except if it take too long, sound a little like code? > Was the implementation in Java? How to cancel the receive by the > timeout alarm? Was it (protocol thread implementation) internally > polling? > The CAN bus was Java on a TINI embedded system for a warehouse system. It implemented a guaranteed delivery data path patterned after the Datagram interface, I called it a Cangram :-) The problem was how to cancel a read as part of a detected protocol or controller error. The hardware was reset via the native code driver which released resources so a restart was successful. I may have garbaged a thread and started a new one as part of it. > > You said later, `a way for a waiting state in native code to > be forced to exit in a reliable, detectable, manner'. Sounds > complicated :) Is this a generic requirement? I think, protocols > often can be implemented to use InputStream (or some other > interface) but also to offer the same interface (like the > decorator pattern). At least when `stacking' such protocols it > can become quite difficult, even if having an own thread per > protocol instance. Of course heavily depends on the project and > situation. Well, interesting topic :) > I think it (reset, stop, interrupt, whatever) should be a general requirement for any Java native interface code. Without it, your application can lock up and there is no reasonable way to regain control. > > The protocols timeout event handler reset the CAN controller to > > get it into a known state for a retry. The reset caused an IO > > exception to the waiting read thread which could check that a > > timeout had caused it. > > Ohh, the CAN controller must be reset? Though they would handle a > whole frame automatically. > I have no clue about this; surely it is very specific and complex. > The native interface resets it. In most cases, the only reason to reset it was so the native interface was freed up for a retry. If they had a interrupt() function, that may have been better. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. > This message may contain confidential and/or privileged information. If > you are not the addressee or authorized to receive this for the addressee, > you must not use, copy, disclose or take any action based on this message or > any information herein. If you have received this message in error, please > advise the sender immediately by reply e-mail and delete this message. Thank > you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/7df09a1e/attachment-0003.html From beat.arnet at gmail.com Mon May 18 13:27:07 2009 From: beat.arnet at gmail.com (Beat Arnet) Date: Mon, 18 May 2009 15:27:07 -0400 Subject: [Rxtx] Error 0x3e3 at termios.c(1301) Message-ID: All, I am experiencing a situation in which RXTX crashes consistently (both with 2.1 and 2.2). Steps to reproduce: - computer with JAVA program is sending bytes over RS-232 to embedded device, embedded device is off - embedded device powers up and transmit startup banner - JVM crashes: Error 0x3e3 at termios.c(1301) Any idea of what I should be looking for? Thanks! Beat # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6163696c, pid=808, tid=9648 # # Java VM: Java HotSpot(TM) Client VM (1.6.0-b105 mixed mode) # Problematic frame: # C 0x6163696c # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x0af7e400): JavaThread "Thread-4" [_thread_in_native, id=9648] siginfo: ExceptionCode=0xc0000005, reading address 0x6163696c Registers: EAX=0xffffffff, EBX=0x78652064, ECX=0x7c90f661, EDX=0x00000005 ESP=0x0c68f990, EBP=0x70706120, ESI=0x6f207469, EDI=0x6e612072 EIP=0x6163696c, EFLAGS=0x00010206 Top of Stack: (sp=0x0c68f990) 0x0c68f990: 6e6f6974 71657220 74736575 0a0a0d2e 0x0c68f9a0: 00000000 0c68f9d4 6d94556c 0daa3cb4 0x0c68f9b0: 74697277 74794265 3e0d2065 0a000a3e 0x0c68f9c0: 7c90cfea 7c80a059 000007d4 0af7e400 0x0c68f9d0: 6d909d8d 000007d4 00000002 6d945bf6 0x0c68f9e0: 0af7e400 00000001 00000000 0af8b024 0x0c68f9f0: 00000032 0af8b038 00000002 00000000 0x0c68fa00: 00000000 0af7e400 0af8b02c 06e85900 Instructions: (pc=0x6163696c) 0x6163695c: [error occurred during error reporting, step 100, id 0xc0000005] Stack: [0x0c640000,0x0c690000), sp=0x0c68f990, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C 0x6163696c [error occurred during error reporting, step 120, id 0xc0000005] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeByte(IZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write(I)V+86 j codeskin.serial.SerialPortRxtx2_1.write(I)V+29 j codeskin.c2oooprog.BootLoader2xxx$PingTask.run()V+87 v ~StubRoutines::call_stub -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/a692f306/attachment-0003.html From cowwoc at bbs.darktech.org Mon May 18 15:43:15 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Mon, 18 May 2009 17:43:15 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <4A119FC1.3090700@trustcommerce.com> Message-ID: <4A11D673.7080508@bbs.darktech.org> I'm in favor of using SerialPortChannel for timeouts and InputStream for non-blocking reads. This will allow us to follow the specification to the letter without any funky side-effects. In my view breaking the InputStream specification is a far greater sin than throwing InterruptedIOException from read(). Using SerialPortChannel and InputStream should allow us to please people in both camps without breaking the specification. Gili Bill Johnson wrote: > Hi Johnny, > > I think a SerialPortChannel could be a good example. It uses an > underlying Socket which uses an underlying implementation to support > open, timeouts, etc. As part of the implementation is where the current > RXTX could come in, provided there is a way to back out of a blocking > situation. > > +BillJ > > On Mon, May 18, 2009 at 1:49 PM, Johnny Luong > > > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Bill Johnson wrote: > | I can add this thought, I think the timeout is part of a protocol, > which > | should sit above RXTX. > > ... > > > Hi Bill, > > This is all conjecture and probably a lot of work in practice, so its > just a train of thought at this point (via NIO)... > > Supposer SerialPort were to implement a method that returned > "SerialPortChannel" which worked along similar lines as a SocketChannel. > ~ Then you could in practice, have a Selector object that did the > timeout > you described above (via a register method)... your read and write > methods could block or not block and it would be a lot easier to drive > multiple serial ports than what you have today. > > - -Johnny > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkoRn8EACgkQnQTBLXttTeXm0gCfaua0ej3Rt0fogRR68bbEFG0Z > BTwAn1s79U8ZU0yj6xcND8gyHzDmKKqq > =ThWj > -----END PGP SIGNATURE----- > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From bschlining at gmail.com Mon May 18 21:20:25 2009 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 18 May 2009 20:20:25 -0700 Subject: [Rxtx] Fwd: image capture In-Reply-To: References: Message-ID: forgot to cc the list ---------- Forwarded message ---------- From: Brian Schlining Date: Mon, May 18, 2009 at 20:19 Subject: Re: [Rxtx] image capture To: "Dr. Douglas Lyon" > Is anyone able to do image capture on a 64 bit mac, using > Java? Yes, I'm doing it from both video capture cards (Kona and Blackmagic) as well as from movie files. I'm only doing it on Java 5 (Mac) though. > QT4J is not loadable using Java 6 (AFAIK). Are you running this on a Mac or PC? Not that it matters I guess. QT4J is (unofficially) dead. It will be officially deprecated when Mac OS X 10.6 (Snow Leopard) is released, but for all practical purposes it's passed away. With each new release of QuickTime in the past year, I do the mad scramble to work around all the changes and bugs that are introduced. I'm working on once such 'fix' right now as a matter of fact. It's too bad too, QT4J was pretty darn powerful. Your best bet going forward is to rip out the QT4J code and replace it with a Mac/PC/Linux abstraction layer. On a Mac there you could try rococoa ( https://rococoa.dev.java.net) or just grab some QTKit samples off of Apples' developer site and write a JNI or JNA interface. On a PC, not sure what to tell you. I don't know what Apple's plans are with QT4J on a PC. They are pushing everyone away from QuickTime (C API) to QTKit (Cocoa/Objective-C). But on a PC ASFAIK there is no QTKit, so it's still QuickTime in the key of C. -- B ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/913800a4/attachment-0003.html From Kustaa.Nyholm at planmeca.com Tue May 19 00:26:27 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 19 May 2009 09:26:27 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A11D673.7080508@bbs.darktech.org> Message-ID: Oops, did it again, did not send this to the list, so we go: > > I'm in favor of using SerialPortChannel for timeouts and InputStream > for non-blocking reads. This will allow us to follow the specification > to the letter without any funky side-effects. > It was not clear to me what Gili is advocating here so I felt I needed to clarify this. > > In my view breaking the InputStream specification is a far greater sin > than throwing InterruptedIOException from read(). Throwing InterruptedIOException from InputStream.read() is just as big sin as it breaks the contract of InterruptedIOException , which says that the *thread* that was performing the IO was interrupted. Coneceptually I feel throwing an exception is a big sin in a situation which is not an error. A time out in a serial communication is almost always to be excepted since it is used to deal with real, live hardware outside the computer and very often it is a part of the higher level communication protocol, for example used to package or frame messages. Exceptions should be reserved for exceptional things not used for something that the programmer expects to happen normally. For one thing they incur an overhead. Granted, in a typical 9600 baud ie 1ms/char case the overhead is negligible, but it is there. On my 2.8 GHz Core 2 Duo try/throw/catch takes about 13 usec. In my view it is simply wrong to throw an exception for timeouts in a serial port. An even greater sin would be breaking existing code for design purity, at least in this case. > Using > SerialPortChannel and InputStream should allow us to please people in > both camps without breaking the specification. > So you are advocating adding a new class SerialPortChannel and a new method SerialPort.getSerialPortChannel() ? That would be acceptable in that it would not brake existing code but totally unnecessary in my view. I suspect most people turn to rxtx as a replacement for javacomm and are only interested in getting the job done. And the current API does this with very nicely. I think we all have better use for our time than to re-invent a serial port API. If the API bothers someone, I suggest they write a wrapper to implement the improvements and release it for interested users, if any. Would be kind of fun to see them struggle with all the API design issues and see what intellectual compromises they have to concede to. As a famous film ends in the sentence: "Nobody's perfect." cheers Kusti From Steffen.DETTMER at ingenico.com Tue May 19 02:12:14 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 19 May 2009 10:12:14 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A11D673.7080508@bbs.darktech.org> Message-ID: <20090519081214.GY17036@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Tue, May 19, 2009 at 09:26 +0300: > Coneceptually I feel throwing an exception is a big sin in a situation > which is not an error. Yes, I think the same. > In my view it is simply wrong to throw an exception for timeouts in > a serial port. Yes, I agree! > An even greater sin would be breaking existing code for design > purity, at least in this case. An even greater sin than that IMHO would be if the new stuff still isn't undoubtful powerful (which would IMHO need to include the possibility to select serial, TCP and other files simultaneously on systems that support it, e.g. for multi-serial-console applications or so). > So you are advocating adding a new class SerialPortChannel and > a new method SerialPort.getSerialPortChannel() ? SerialPortChannel would be a java.nio.channels.SelectableChannel or so? Or maybe a AbstractGatheringInterruptibleSelectableReadableWritableByteChannel. (the java name for `int fd' lol - SCNR). If changeing, I think an option could be to implement straightforward in native code offering its natural API (full timeout support, maybe as mandatory parameter, not dealing with Channel, Streams, source&sink, reactor&proactor patterns :-)). On top of that then both Channel and Stream and maybe something else for someone else. > That would be acceptable in that it would not brake existing code but > totally unnecessary in my view. I suspect most people turn to rxtx > as a replacement for javacomm and are only interested in getting the > job done. Yes, and most probably just have a few simultaneous connections. Others may need to have a dedicated, specialized and highly optimized JNI impl anyway (I guess). > If the API bothers someone, I suggest they write a wrapper to > implement the improvements and release it for interested users, > if any. Yes, actually that was what we did, but sometimes it was a bit cumbersome (because of InputStream and stuff). We implemented on top of that (instead of native interfaces or such) assuming that those interfaces won't change (but JNI interfaces probably are considered implementation details and thus probably will change). > Would be kind of fun to see them struggle with all the API > design issues and see what intellectual compromises they have > to concede to. Yeah, and then a nio successor comes and everone wanna go with it then :-) oki, Steffen ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Tue May 19 02:33:35 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 19 May 2009 10:33:35 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> Message-ID: <20090519083335.GZ17036@elberon.bln.de.ingenico.com> Hi! * Bill Johnson wrote on Mon, May 18, 2009 at 15:24 -0400: > * On Mon, May 18, 2009 at 1:54 PM, Steffen DETTMER wrote: > > * Bill Johnson wrote on Mon, May 18, 2009 at 13:08 -0400: > > > I can add this thought, I think the timeout is part of a > > > protocol, which should sit above RXTX. > > > > Probably actually on both levels timeouts can be helpful; if > > there is some PPP/TCP or other full duplex multiplexing > > protcol I think at least it is nice to be able to read with > > some reasonable timeout(s). > > I think timeout at the native level does not fit well with a > read() concept of timeout because it depends on the protocol > not really on the read(). What is special about `native level' to gain a special handling? I think all levels should support timeouts. Of course the read timeout an application invokes on a TCP stream has no direct relation to a PPP timeout and intercharacter timeouts on serial lines often depend on serial speed, CPU speed, required response timings, interrupt load etc, I think. So yes, I agree that protocols (often) define needed timeouts (to the lower layer) and the lower layer must offer support for timeouts. Is this what you mean with `depends on the protocol'? > > (this Bosch car protocol?) > > > > But if the protocol implementation knows the timeout value, > > wouldn't it be easier and suited better to have some way to apply > > it to the reads without needing multithreading? > > If you are waiting on a read and you are waiting on a timeout at the same > time, that is two logical threads. Ohh no, I disagree. I think, only if you have plenty of resources it is possible to waste a whole thread to watch a clock. When you have to read 100 connections of course you can use 100 threads, but better would be 1 thread with a select (or epoll or whatever), especially when assuming that the timeout is just a wait (thread sleep) time (when the OS is buffering the data anyway, which on Java running OSes probably is common). > Maybe you are looping check for one of two condition, character > or timeout, but I think its the same logically as waiting for a > character or a timeout exception. It is a special case where > you try to read except if it take too long, sound a little like > code? But isn't a maximum time a natural property of waiting? When you wait for someone for a meeting or so, you look to your watch from time to time and after half an hour or so you leave or continue your business. Select style IMHO is logically more event based than multi-threaded synchronous, but for applications or protocol implementations I found it comfortable when timeouts can be configured at any time. We even have two optional timeout parameters on our read function which eases implementing requirements like `receive both characters within 200 ms or reply with X'. > The CAN bus was Java on a TINI embedded system for a warehouse > system. It implemented a guaranteed delivery data path > patterned after the Datagram interface, I called it a Cangram > :-) The problem was how to cancel a read as part of a detected > protocol or controller error. The hardware was reset via the > native code driver which released resources so a restart was > successful. I may have garbaged a thread and started a new one > as part of it. cool :-) guess this was a very interesting project :) > I think it (reset, stop, interrupt, whatever) should be a > general requirement for any Java native interface code. Without > it, your application can lock up and there is no reasonable way > to regain control. alternatively, it could be required that any JNI function must return after some latest amount of time (i.e. specifying the maximum invocation time). I think, third-path-interruptions, maybe triggered from different threads, could quickly make code complicated because suddenly so many possible code paths can happen and they are hard to test (and cover). Personally, I think this is a major point against avoidable thread usage (even more if threads are not orthogonal) - hard to test, hard to ensure and prove it really is wrong always. Of course often enough it is needed anyway... oki, Steffen ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From michaeltandy at googlemail.com Tue May 19 08:33:09 2009 From: michaeltandy at googlemail.com (Michael Tandy) Date: Tue, 19 May 2009 15:33:09 +0100 Subject: [Rxtx] Rxtx native library loading Message-ID: <302aa0340905190733r4009e394v335b3ef47d84ffb5@mail.gmail.com> Attached is a patch which changes native library loading in Rxtx. Specifically, it makes two changes: 1. Looks in the directory RXTXcomm.jar is in for a native library, prior to searching java.library.path 2. Produces more informative error messages (in addition to the normal exceptions) if the native library cannot be found. The key benefits of this are: (a) to simplify setup; no need for administrator access to put things in shared/system directories, just unzip a file (containing my program as a .jar, RXTXcomm.jar, rxtxSerial.dll, librxtxSerial.so, and so on) and you're good to go; (b) If you've got multiple rxtx versions on your path (e.g. MATLAB puts its bin directory on your path, containing a copy of rxtxSerial.dll) you get the library file matching your jar file; (c) you don't need a big -Djava.library.path= every time you start your program; (d) if your native library file is missing, the error message is a bit more helpful (tells you where is being searched and for what); and (e) If the new code fails, it reverts to what the old code did, so it should be fully backwards-compatible. What do you think - is it worth including these changes in the main version of rxtx? Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: libraryloader.diff Type: text/x-diff Size: 10293 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090519/641c6573/attachment-0002.bin From bill7007 at gmail.com Tue May 19 12:37:32 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Tue, 19 May 2009 14:37:32 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090519083335.GZ17036@elberon.bln.de.ingenico.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> <20090519083335.GZ17036@elberon.bln.de.ingenico.com> Message-ID: On Tue, May 19, 2009 at 4:33 AM, Steffen DETTMER wrote: ... > > Is this what you mean with `depends on the protocol'? Native code is run time speed efficient, and that is important. I think I am saying, design wise, the function is read(). Timeout is a condition on read() only required by whatever comm protocol or comm logic you are using. I am thinking the whole purpose of SerialPort object is to represent a serial port so it should only contains methods and attributes of a serial port. A timeout is an event, part of the communication logic that is using that port. Wow, what a discussion. I had to go back and read it all to gather thoughts. I see multiple issues here. They coexist. 1) CommPort timeout implementation 2) Native blocking behavior and possible interruptions I think my protocol timeout thought was to state that the CommPort timeout may not be the best way implement a protocol timeout, but an alternative needs a blocking interrupt capability. Maybe that should be its own discussion. I do agree with the commandment, Thou shalt not modify the reference API. To focus back on Sun's CommPort interface, it does define a timeout that is optionally implemented and could be useful. I think a description of CommPort.getInputStream together with InputStream.read() leads to the implementation behavior: read() returns "the next byte of data, or -1 if the end of the stream is reached." So, end of stream must mean one of: 1) a timeout 2) "framing errors" (plural meaning parity and overrun too?) read(byte[]?b) returns "the total number of bytes read into the buffer, or -1 is there is no more data because the end of the stream has been reached." An end of stream here causes a return of the number read so far, or -1 if no data was yet read. How to determine cause of end of stream is a weakness of this API. Capturing a SerialPortEvent includes the framing error but not timeout. +BillJ From Steffen.DETTMER at ingenico.com Tue May 19 13:10:26 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 19 May 2009 21:10:26 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> <20090519083335.GZ17036@elberon.bln.de.ingenico.com> Message-ID: <20090519191025.GF17036@elberon.bln.de.ingenico.com> * Bill Johnson wrote on Tue, May 19, 2009 at 14:37 -0400: > methods and attributes of a serial port. A timeout is an event, part > of the communication logic that is using that port. (or the absence of data arrived events?) > read() returns "the next byte of data, or -1 if the end of the stream > is reached." > So, end of stream must mean one of: > 1) a timeout > 2) "framing errors" (plural meaning parity and overrun too?) I think neither timeout nor framing errors are end of stream (end of file) but only `remote DTR drop' is. I'm not sure (and always confuse) to which input line its maps and whether it is hi or lo active... I think, on linux, at least some versions, this worked well because when one side called close(fd) the other side read the EOF in exactly this moment. In general I think this is not reliable (different OSes surely handle it differently and it probably depends on several other things). With TCP sockets this can be expected to work (when one side shuts down its write channel, the other reads EOF after reading all data, which of course is returned first). Well, but probably some OS out there will be different just to annoy us :-) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From cowwoc at bbs.darktech.org Tue May 19 14:28:36 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 19 May 2009 16:28:36 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <4A131674.6000906@bbs.darktech.org> Guys, I am feeling very frustrated with this whole discussion. 1) There is no doubt that the current implementation breaks the InputStream API. A return value of -1 is already mapped to end-of-stream. For this reason, you *cannot* map the same value to a timeout. This is basic design-by-contract! 2) RXTX's implementation does not match javax.comm 100%. There are plenty of situations where the two implementations diverge. I am frustrated that people want to simultaneously freeze the APIs and fix issues that *cannot* be fixed purely in the implementation layer. 3) "Premature optimization is the root of all evil" and yet I see people complaining that exception handling costs 13 usec. Java places emphasizes correctness above performance. If you don't get that you shouldn't be coding in Java. More specific replies below... > Throwing InterruptedIOException from InputStream.read() is just as > big sin as it breaks the contract of InterruptedIOException , which > says that the *thread* that was performing the IO was interrupted. A thread getting interrupted is not the same as Thread.interrupt(). My interpretation is that interrupting the operation due to a timeout is a perfectly legal form of "thread interruption". Even with respect to Thread.interrupt(), you can't interrupt a thread, only the work it is executing. > Coneceptually I feel throwing an exception is a big sin in a situation > which is not an error. Exceptions refer to "exceptional circumstances" which is not the same as "errors". By that I mean that the "normally" the method returns 0-255, but exceptional cases such as timeouts are perfectly legal. > A time out in a serial communication is > almost always to be excepted since it is used to deal with real, live > hardware outside the computer I disagree. Some application-level protocols don't use timeouts at all. Why would your argument be true for serial connections but not sockets? > So you are advocating adding a new class SerialPortChannel and > a new method SerialPort.getSerialPortChannel() ? > > That would be acceptable in that it would not brake existing code but > totally unnecessary in my view. I suspect most people turn to rxtx > as a replacement for javacomm and are only interested in getting the > job done. And the current API does this with very nicely. I think > we all have better use for our time than to re-invent a serial port > API. The classic IO api is synchronous whereas NIO channels are asynchronous. Trying to retrofit timeouts on top of the old APIs will never be as clean as using NIO which is designed specifically for this purpose. Gili From tjarvi at qbang.org Tue May 19 17:19:15 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 May 2009 17:19:15 -0600 (MDT) Subject: [Rxtx] Rxtx native library loading In-Reply-To: <302aa0340905190733r4009e394v335b3ef47d84ffb5@mail.gmail.com> References: <302aa0340905190733r4009e394v335b3ef47d84ffb5@mail.gmail.com> Message-ID: On Tue, 19 May 2009, Michael Tandy wrote: > Attached is a patch which changes native library loading in Rxtx. > > Specifically, it makes two changes: > > 1. Looks in the directory RXTXcomm.jar is in for a native library, > prior to searching java.library.path > 2. Produces more informative error messages (in addition to the normal > exceptions) if the native library cannot be found. > > The key benefits of this are: > (a) to simplify setup; no need for administrator access to put things > in shared/system directories, just unzip a file (containing my program > as a .jar, RXTXcomm.jar, rxtxSerial.dll, librxtxSerial.so, and so on) > and you're good to go; > (b) If you've got multiple rxtx versions on your path (e.g. MATLAB > puts its bin directory on your path, containing a copy of > rxtxSerial.dll) you get the library file matching your jar file; > (c) you don't need a big -Djava.library.path= every time you start your program; > (d) if your native library file is missing, the error message is a bit > more helpful (tells you where is being searched and for what); > and (e) If the new code fails, it reverts to what the old code did, so > it should be fully backwards-compatible. > > What do you think - is it worth including these changes in the main > version of rxtx? > > Michael > Hi Michael, We will be putting a patch like yours in as soon as we release 2.2. The release was going to be mothers day but I got caught up :) I hope to do it next weekend. After that we will be looking at web installs which overlaps with your solution. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 19 17:44:25 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 May 2009 17:44:25 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A131674.6000906@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> Message-ID: On Tue, 19 May 2009, cowwoc wrote: >> A time out in a serial communication is >> almost always to be excepted since it is used to deal with real, live >> hardware outside the computer > > I disagree. Some application-level protocols don't use timeouts at all. > Why would your argument be true for serial connections but not sockets? > Hi Gili One fundamental difference between sockets, file io and RS232 communication is that sockets and file systems provide error handling. If a packet is lost, it is resent without the java API knowing about it. RS232 is actually an electrical signal standard. Serial communication exposes a UART without any meaningful error handling and cludgy error reporting. Given the above, ignoring timeouts is not really a valid rxtx level option. We could have a new option/method that allows you to get an InputStream or Channel that behaves as you wish. If we change the InputStream returned by getInputStream(), that would be change in the API (version 3.0) that forks our userbase. So I guess my question is whether or not you are trying to change the object returned by getInputStream or just looking for a means to get a different object you would like to define be returned. The later is far easier to accommodate. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 19 18:38:06 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 May 2009 18:38:06 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090519191025.GF17036@elberon.bln.de.ingenico.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> <20090519083335.GZ17036@elberon.bln.de.ingenico.com> <20090519191025.GF17036@elberon.bln.de.ingenico.com> Message-ID: On Tue, 19 May 2009, Steffen DETTMER wrote: > * Bill Johnson wrote on Tue, May 19, 2009 at 14:37 -0400: >> methods and attributes of a serial port. A timeout is an event, part >> of the communication logic that is using that port. > > (or the absence of data arrived events?) > >> read() returns "the next byte of data, or -1 if the end of the stream >> is reached." >> So, end of stream must mean one of: >> 1) a timeout >> 2) "framing errors" (plural meaning parity and overrun too?) > > I think neither timeout nor framing errors are end of stream (end > of file) but only `remote DTR drop' is. I'm not sure (and always > confuse) to which input line its maps and whether it is hi or lo > active... > There really is an end of input in termios that would match up fairly close in theory. The problem is it isnt really used as far as I know. termois.c_cc[VEOF] - the end of input character. I assume it is control-d. If you have a terminal open, try typing it into the shell prompt :) We even have some access to it in rxtx as extensions to commapi: private native byte nativeGetEndOfInputChar( ) throws UnsupportedCommOperationException; private native boolean nativeSetEndOfInputChar( byte b ) throws UnsupportedCommOperationException; GPIB has an entire wire dedicated to "EOI." -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue May 19 19:07:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 19 May 2009 21:07:34 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> Message-ID: <4A1357D6.9090705@bbs.darktech.org> Hi Trent, > RS232 is actually an electrical signal standard. Serial communication > exposes a UART without any meaningful error handling and cludgy error > reporting. > > Given the above, ignoring timeouts is not really a valid rxtx level > option. We could have a new option/method that allows you to get an > InputStream or Channel that behaves as you wish. Why? You could always use available() alongside blocking reads. > If we change the InputStream returned by getInputStream(), that would be > change in the API (version 3.0) that forks our userbase. > > So I guess my question is whether or not you are trying to change the > object returned by getInputStream or just looking for a means to get a > different object you would like to define be returned. > > The later is far easier to accommodate. I expect users to use getInputStream() for blocking reads and getInputChannel() for non-blocking reads. I understand your objections and normally I'd agree to wait for version 3.0 but RXTX's violation of the specification is a critical flaw in my opinion. Don't take my word for it... Take a look at this post I just ran across: http://stackoverflow.com/questions/611760/java-inputstream-read-blocking ------ quote ------- A read of -1 isn't doesn't mean, "there's no data present on this attempt," it means, "the stream is closed and there will never be any data so stop asking." If the end of the stream has not been reached, a read() call will block, just as the documentation specifies. [...] I've only used javax.comm for serial port I/O, and it implements InputStream as intended. It's possible that the rxtx implementation violates the contract of InputStream.read(), but if so, that's a very bad thing. Any code that was written to work with InputStream in general relies on the fact that -1 means EOF. Passing a broken java.io.InputStream to such code will cause problems. If rxtx supports non-blocking I/O, they should have created their own interface for reading, not extended InputStream. ------ quote ------- We learn two things from this post: 1) javax.comm respects the InputStream contract. It does not return -1 on timeouts. Seeing how you've written that any deviation from the javax.comm implementation is a bug I would suggest that this should be fixed immediately. 2) Violating the superclass specification can introduce an untold number of bugs. For example, I spent hours trying to figure out why BufferedReader.readLine() was returning null while the connection was still open. Gili From tjarvi at qbang.org Tue May 19 19:23:13 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 May 2009 19:23:13 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A1357D6.9090705@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> Message-ID: On Tue, 19 May 2009, cowwoc wrote: > > 1) javax.comm respects the InputStream contract. It does not return -1 on > timeouts. Seeing how you've written that any deviation from the javax.comm > implementation is a bug I would suggest that this should be fixed > immediately. > Hi Gili What is the observed behavior of javax.comm on timeout? Are you sure it didn't just disable timeouts by default? -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue May 19 19:37:24 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 19 May 2009 21:37:24 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> Message-ID: <4A135ED4.3090608@bbs.darktech.org> Trent Jarvi wrote: >> 1) javax.comm respects the InputStream contract. It does not return -1 >> on timeouts. Seeing how you've written that any deviation from the >> javax.comm implementation is a bug I would suggest that this should be >> fixed immediately. > What is the observed behavior of javax.comm on timeout? Are you sure it > didn't just disable timeouts by default? I'm not sure. Unfortunately, I've never gotten javax.comm to work under Windows and I don't have access to any other platform at this time. I assume that you've used javax.comm before, so I encourage you to try it on your end. Whatever they did, I really don't think that Sun would have violated the InputStream specification by returning -1 on timeout. As the BufferedReader.readLine() example shows, doing so triggers a lot of bugs. Gili From tjarvi at qbang.org Tue May 19 20:01:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 May 2009 20:01:53 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A135ED4.3090608@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> <4A135ED4.3090608@bbs.darktech.org> Message-ID: On Tue, 19 May 2009, cowwoc wrote: > Trent Jarvi wrote: >>> 1) javax.comm respects the InputStream contract. It does not return -1 on >>> timeouts. Seeing how you've written that any deviation from the javax.comm >>> implementation is a bug I would suggest that this should be fixed >>> immediately. > >> What is the observed behavior of javax.comm on timeout? Are you sure it >> didn't just disable timeouts by default? > > I'm not sure. Unfortunately, I've never gotten javax.comm to work > under Windows and I don't have access to any other platform at this time. I > assume that you've used javax.comm before, so I encourage you to try it on > your end. Whatever they did, I really don't think that Sun would have > violated the InputStream specification by returning -1 on timeout. As the > BufferedReader.readLine() example shows, doing so triggers a lot of bugs. > I've actually never used the Sun implementation. RXTX and CommAPI have very different origins that overlap with Kevin Hester's "JCL" patch to bring them together. The rest has been done from the docs. Default settings have always been a source of confusion which is why I ask. Disabled timeouts/thresholds would behave like you expect. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue May 19 20:30:22 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 19 May 2009 22:30:22 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> <4A135ED4.3090608@bbs.darktech.org> Message-ID: <4A136B3E.7010704@bbs.darktech.org> Trent Jarvi wrote: > What is the observed behavior of javax.comm on timeout? Are you sure > it didn't just disable timeouts by default? Can someone who has used javax.comm please investigate this and let us know? Thanks, Gili From Steffen.DETTMER at ingenico.com Wed May 20 02:30:08 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 20 May 2009 10:30:08 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A131674.6000906@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> Message-ID: <20090520083008.GH17036@elberon.bln.de.ingenico.com> * cowwoc wrote on Tue, May 19, 2009 at 16:28 -0400: > Guys, I am feeling very frustrated with this whole discussion. (Me too, but probably for different reason :-)) > 1) There is no doubt that the current implementation breaks the > InputStream API. (which must happen, because InputStream as defined is less usable) > A return value of -1 is already mapped to end-of-stream. For > this reason, you *cannot* map the same value to a timeout. This > is basic design-by-contract! Currently (actually we are still using RXTX-2.1-7 which surely isn't the latest version :)), in case of timeout read(byte[]) returns 0. We have a wrapper implementation (which because of some rxtx timeout precision issues) might be a few lines more than needed but provides timeout precision typical better than 100ms (for us, this is sufficient). I wrote about it here some years ago. So it's possible to work with rxtx even with InputStream. Not very comfortable thanks for InputStream, but it works. Java developers expect InputStream (with its limitations). I was told this several times. May the java and javax APIs suck or not, but it is what most java developers are used to use, expect and what we live with in so many other areas, too. > 2) RXTX's implementation does not match javax.comm 100%. There > are plenty of situations where the two implementations diverge. > I am frustrated that people want to simultaneously freeze the > APIs and fix issues that *cannot* be fixed purely in the > implementation layer. As already written, I think a `real complete exhaustive fix' isn't possible or desired here for various reasons. The current way works well and complies to java stuff as much as possible (the differences are enforced logically and the InputStream specification IMHO is simply wrong). Now why change, requiring people to redevelop their applications or wrappers? Why not alternatively publish one of those wrappers (yours? :-)) under a public license and/or add it to rxtx allowing people that want exceptions allowing them to use configurable exceptions (for example)? > 3) "Premature optimization is the root of all evil" and yet I > see people complaining that exception handling costs 13 usec. > Java places emphasizes correctness above performance. If you > don't get that you shouldn't be coding in Java. In general, also `oversimplification is a root of evil' and IMHO nice examples can be found in Java APIs, but this is the way `everyone' goes. Raping exceptions as return codes IMHO is not a performance problem but a design problem (in a non-RAII-aware language which is not allowing ensured resource cleanups by guaranteed destructors this is a real big problem, IMHO). I don't understand the discussion. We have a read returning number of bytes read. We have situations where no byte is read. Now the API doesn't tell that in this case zero should be returned, but I think this is so damn obvious, isn't it?? > > A time out in a serial communication is almost always to be > > excepted since it is used to deal with real, live hardware > > outside the computer > > I disagree. Some application-level protocols don't use timeouts > at all. Why would your argument be true for serial connections > but not sockets? In general, everything has (or should have) timeouts /or/ be under control of something. Technically, the latter may require use `timeouts in a loop' (some polling). TCP has timeouts, for instance retransmission timeouts. Situations were no timeouts are defined in TCP (was it e.g. FIN_WAIT?) in the past lead to issues. On real OSes there are also UDP sockets, UNIX Domain Sockets and whatever else - and all of them and serial ports can accessed via one and the same API and select'd at the same time: timeout supported is simply built-in. For complex protcols, like TCP, all the heaps of defined timeouts might not be as visible as for serial case, where typical applications handle details themself, but they exist. > The classic IO api is synchronous whereas NIO channels are > asynchronous. Trying to retrofit timeouts on top of the old > APIs will never be as clean as using NIO which is designed > specifically for this purpose. I think classic is BSD socket API, which IMHO looks like a natural evolution of classic unix APIs. Works also for serial and everything (at least on unix and cygwin). I think Java people didn't saw the big picture and tried to simplify but oversimplified, assuming, InputStream could be used for all types of communication. Actually, it even can, but not alone (usually, you additionally need OutputStream and some ioctl). Now of course it was nice and sexy to critise the non-type-safe ioctl and select and to drop it - but this of course is no solution. Just ignoring the difficulties rarely helps. NIO is a bit more BSD socket API style, a step into the direction where everything comes from. Next version might take another step and reach the goal. Who knows. As far as I know none of the issues that lead to NIO (mostly performance and scalability) apply to rxtx. The only thing that seems to appy is that some buggy Javadoc tells InputStream would be blocking, available has no timeout, write timeouts are also not supported - and read(byte[]) never returns 0. Which quickly, easily and straightforward `fixes' the issues. That is what rxtx did. Isn't this fine? oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From m.j.tandy at warwick.ac.uk Wed May 20 03:01:51 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 20 May 2009 10:01:51 +0100 Subject: [Rxtx] InputStream timeouts In-Reply-To: <302aa0340905200201r912d9d0m6c9e1e41e049f1df@mail.gmail.com> References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> <302aa0340905200201r912d9d0m6c9e1e41e049f1df@mail.gmail.com> Message-ID: <302aa0340905200201t13a31a4bq30f60042c50fde63@mail.gmail.com> > 2) Violating the superclass specification can introduce an untold number > of bugs. For example, I spent hours trying to figure out why > BufferedReader.readLine() was returning null while the connection was > still open. We're discussing what the read() method does on timeout - but isn't the failure of BufferedReader.readLine caused by read(byte[] b, int off, int len) returning '0 bytes read' - not caused by what the read() method does on timeout? I mean, when I run the code below (Java 1.6.0_13-b03 / Sun JDK 6) the output is: Attempting to read a line... program called inputstream's read(byte[] b, int off, int len) java.io.IOException: Underlying input stream returned zero bytes ? ? ? ?at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) ? ? ? ?at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) ? ? ? ?at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) ? ? ? ?at java.io.InputStreamReader.read(InputStreamReader.java:167) ? ? ? ?at java.io.BufferedReader.fill(BufferedReader.java:136) ? ? ? ?at java.io.BufferedReader.readLine(BufferedReader.java:299) ? ? ? ?at java.io.BufferedReader.readLine(BufferedReader.java:362) ? ? ? ?at inputstreamtest.Main.main(Main.java:14) And if I look at the source code for StreamDecoder.java [1] I see the following lines: ?283 ? ? ? ? ? ? ? int n = in.read(bb.array(), bb.arrayOffset() + pos, rem); ?284 ? ? ? ? ? ? ? if (n < 0) ?285 ? ? ? ? ? ? ? ? ? return n; ?286 ? ? ? ? ? ? ? if (n == 0) ?287 ? ? ? ? ? ? ? ? ? throw new IOException("Underlying input stream returned zero bytes"); Which kind of makes sense, because the javadoc for read(byte[] b, int off, int len) [2] does explicitly say that "If len is zero, then no bytes are read and 0 is returned; otherwise, there is an attempt to read at least one byte. If no byte is available because the stream is at end of file, the value -1 is returned; otherwise, at least one byte is read and stored into b." Is this the problem that you encountered? Michael [1] http://www.docjar.com/html/api/sun/nio/cs/StreamDecoder.java.html [2] http://java.sun.com/javase/6/docs/api/java/io/InputStream.html#read(byte[],%20int,%20int) // CODE BEGINS HERE package inputstreamtest; import java.io.BufferedReader; import java.io.IOException; import java.io.InputStream; import java.io.InputStreamReader; public class Main { ? ?public static void main(String[] args) { ? ? ? ?BufferedReader in = new BufferedReader(new InputStreamReader(new FakeInputStream())); ? ? ? ?System.out.println("Attempting to read a line..."); ? ? ? ?try { ? ? ? ? ? ?in.readLine(); ? ? ? ?} catch (IOException e) { ? ? ? ? ? ?e.printStackTrace(); ? ? ? ?} ? ?} ? ?private static class FakeInputStream extends InputStream { ? ? ? ?@Override ? ? ? ?public int read(byte[] b, int off, int len) { ? ? ? ? ? ?System.out.println("program called inputstream's read(byte[] b, int off, int len)"); ? ? ? ? ? ?return 0; ? ? ? ?} ? ? ? ?@Override ? ? ? ?public int read() throws IOException { ? ? ? ? ? ?System.out.println("program called inputstream's read()"); ? ? ? ? ? ?return -1; ? ? ? ?} ? ?} } From Steffen.DETTMER at ingenico.com Wed May 20 03:16:20 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 20 May 2009 11:16:20 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> <20090519083335.GZ17036@elberon.bln.de.ingenico.com> <20090519191025.GF17036@elberon.bln.de.ingenico.com> Message-ID: <20090520091620.GI17036@elberon.bln.de.ingenico.com> * Trent Jarvi wrote on Tue, May 19, 2009 at 18:38 -0600: > >I think neither timeout nor framing errors are end of stream (end > >of file) but only `remote DTR drop' is. I'm not sure (and always > >confuse) to which input line its maps and whether it is hi or lo > >active... > > There really is an end of input in termios that would match up > fairly close in theory. The problem is it isnt really used as > far as I know. > > termois.c_cc[VEOF] - the end of input character. I assume it > is control-d. If you have a terminal open, try typing it into > the shell prompt :) Ahh yes, this way it was! (what means `logged out' and why my modem has no carrier?! :)) With a null modem cable and a C++ implementation I tried it and found that you are right, it is working with ^D (but not with DTR as I claimed), thanks for the correction. In `stty raw' ^D is 0x04 but after `stty sane' ^D works as end of input character, as you said. select(2) tells ready for read and read(2) return 0 bytes, which means EOF :-) (Well, in strict pure theory I think this could be considered a property of the terminal line discipline canonical mode, which IMHO could be considered a protocol property) BTW, is someone using this EOF in general? Our C++ implementation supports both it seems it (EOF detection) was never used. I guess it depends on the domain someone is working in? I could imagine that some micro controller control interfaces use that? oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed May 20 03:32:00 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 20 May 2009 11:32:00 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> <20090519083335.GZ17036@elberon.bln.de.ingenico.com> <20090519191025.GF17036@elberon.bln.de.ingenico.com> Message-ID: <20090520093200.GK17036@elberon.bln.de.ingenico.com> ps. our java implementation using RXTX-2.1-7 (surely very old) does not detect the ^D in `stty sane' mode. also, just BTW, about the IOException interruption discussion. When I aborted the java command line test program by ^C, I got IOException: java.io.IOException: Interrupted system call in readArray which IMHO shows that Kusti is right. The code not detecting EOF is similar to: port_.enableReceiveTimeout(intTimeout); bytesRead = port_.getInputStream().read( buffer, totalBytesRead, bytesRequested ); switch (bytesRead) { case -1: readClosedByPeer_ = true; break; case 0: // log interchar timeout if (totalBytesRead > 0) { rs232Logger_.finest( "Intercharacter timeout (" + getByteReadTimeout() + " ms) while reading, might be Ok. Returning " + totalBytesRead + " bytes read so far" ); } if (!ENABLE_RECEIVE_TIMEOUT_PRECISION_LOGGING) { break; } So actually I don't know if readClosedByPeer ever worked (we don't use it anyway I think). oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Wed May 20 03:57:30 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 12:57:30 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <302aa0340905200201t13a31a4bq30f60042c50fde63@mail.gmail.com> Message-ID: > From: Michael Tandy > And if I look at the source code for StreamDecoder.java [1] I see the > following lines: > ?283 ? ? ? ? ? ? ? int n = in.read(bb.array(), bb.arrayOffset() + pos, rem); > ?284 ? ? ? ? ? ? ? if (n < 0) > ?285 ? ? ? ? ? ? ? ? ? return n; > ?286 ? ? ? ? ? ? ? if (n == 0) > ?287 ? ? ? ? ? ? ? ? ? throw new IOException("Underlying input stream > returned zero bytes"); > > Which kind of makes sense, because the javadoc for read(byte[] b, int > off, int len) [2] does explicitly say that "If len is zero, then no > bytes are read and 0 is returned; otherwise, there is an attempt to > read at least one byte. If no byte is available because the stream is > at end of file, the value -1 is returned; otherwise, at least one byte > is read and stored into b." Not realy relevant for the discussion but out of curiosity I had peek at the code you quoted and just a few lines above we see: 278 int lim = bb.limit(); 279 int pos = bb.position(); 280 assert (pos <= lim); 281 int rem = (pos <= lim ? lim - pos : 0); 282 assert rem > 0; If asserts are disabled (the default IIRC) then 'rem' could be 0 in which case throwing exception on line 287 is not correct in that it is legal for read(byte[]) to return under that circumstance. Of course it maybe that the design of StreamDecoder otherwise guarantees that lim > pos but this just shows how difficult it is to be logically consistent all the time. Further browsing the StreamDecoder and CharsetDecorder classes it seems, at least superficially, that nothing has been gained by checking and throwing an exception, the rest of code would have worked correctly even if the the read on line 283 would return 0. All code that I've ever written have handled read(byte[]) returning 0 correctly (touch wood!) taking it on it's stride. Why not, you need to prepare for read to return less than what you asked so it naturally falls to handle the case of 0 also. From Kustaa.Nyholm at planmeca.com Wed May 20 04:06:12 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 13:06:12 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090520083008.GH17036@elberon.bln.de.ingenico.com> Message-ID: > From: Steffen DETTMER > >> 1) There is no doubt that the current implementation breaks the >> InputStream API. > (which must happen, because InputStream as defined is less usable) > Exactly. > Now why change, requiring people to redevelop their applications > or wrappers? Why not alternatively publish one of those wrappers > (yours? :-)) under a public license and/or add it to rxtx > allowing people that want exceptions allowing them to use > configurable exceptions (for example)? > Hear,hear, agree whole heartedly! > > I don't understand the discussion. We have a read returning > number of bytes read. We have situations where no byte is read. > Now the API doesn't tell that in this case zero should be > returned, but I think this is so damn obvious, isn't it?? To me it is soooooo obvious. > > The only thing that seems to appy is that some buggy Javadoc > tells InputStream would be blocking, available has no timeout, > write timeouts are also not supported - and read(byte[]) never > returns 0. Which quickly, easily and straightforward `fixes' the > issues. That is what rxtx did. Isn't this fine? It is fine. It ain't broken, don't fix it. This is mainly a documentation issue. When the map and scenery disagree trust the scenery. Thanks Steffen for summing it up so nicely! cheers Kusti From cowwoc at bbs.darktech.org Wed May 20 04:39:31 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 06:39:31 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090520083008.GH17036@elberon.bln.de.ingenico.com> References: <4A131674.6000906@bbs.darktech.org> <20090520083008.GH17036@elberon.bln.de.ingenico.com> Message-ID: <4A13DDE3.8070703@bbs.darktech.org> Steffen DETTMER wrote: > * cowwoc wrote on Tue, May 19, 2009 at 16:28 -0400: >> Guys, I am feeling very frustrated with this whole discussion. > > (Me too, but probably for different reason :-)) > >> 1) There is no doubt that the current implementation breaks the >> InputStream API. > > (which must happen, because InputStream as defined is less usable) Not true. Either we follow the InputSteam specification or we define our own interface. Breaking the specification in this way will trigger unpredictable bugs. > Currently (actually we are still using RXTX-2.1-7 which surely > isn't the latest version :)), in case of timeout read(byte[]) > returns 0. > > I don't understand the discussion. We have a read returning > number of bytes read. We have situations where no byte is read. > Now the API doesn't tell that in this case zero should be > returned, but I think this is so damn obvious, isn't it?? Actually, the Javadoc for read(byte[]) says that at least one byte must be read: "If the length of b is zero, then no bytes are read and 0 is returned; otherwise, there is an attempt to read at least one byte. If no byte is available because the stream is at the end of the file, the value -1 is returned; otherwise, at least one byte is read and stored into b." > In general, everything has (or should have) timeouts /or/ be > under control of something. Technically, the latter may > require use `timeouts in a loop' (some polling). TCP has > timeouts, for instance retransmission timeouts. Situations were > no timeouts are defined in TCP (was it e.g. FIN_WAIT?) in the > past lead to issues. On real OSes there are also UDP sockets, > UNIX Domain Sockets and whatever else - and all of them and > serial ports can accessed via one and the same API and select'd > at the same time: timeout supported is simply built-in. > For complex protcols, like TCP, all the heaps of defined timeouts > might not be as visible as for serial case, where typical > applications handle details themself, but they exist. Fair enough, but "timeouts in a loop" -- using available() -- don't break the InputStream specification. > NIO is a bit more BSD socket API style, a step into the direction > where everything comes from. Next version might take another step > and reach the goal. Who knows. As far as I know none of the > issues that lead to NIO (mostly performance and scalability) > apply to rxtx. NIO allows you to select() on a channel with a timeout, which is the point of contention. > The only thing that seems to appy is that some buggy Javadoc > tells InputStream would be blocking, available has no timeout, > write timeouts are also not supported - and read(byte[]) never > returns 0. Which quickly, easily and straightforward `fixes' the > issues. That is what rxtx did. Isn't this fine? I'm not sure I understand. I get that you dislike that InputStream doesn't provide facilities for non-blocking reads but that is just life. You're supposed to either create your own interface or use NIO for that. In my view, breaking the superclass contract is always worse than inconveniencing yourself. Gili From cowwoc at bbs.darktech.org Wed May 20 04:41:14 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 06:41:14 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <302aa0340905200201t13a31a4bq30f60042c50fde63@mail.gmail.com> References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> <302aa0340905200201r912d9d0m6c9e1e41e049f1df@mail.gmail.com> <302aa0340905200201t13a31a4bq30f60042c50fde63@mail.gmail.com> Message-ID: <4A13DE4A.70704@bbs.darktech.org> Yes. Gili Michael Tandy wrote: >> 2) Violating the superclass specification can introduce an untold number >> of bugs. For example, I spent hours trying to figure out why >> BufferedReader.readLine() was returning null while the connection was >> still open. > > We're discussing what the read() method does on timeout - but isn't > the failure of BufferedReader.readLine caused by read(byte[] b, int > off, int len) returning '0 bytes read' - not caused by what the read() > method does on timeout? > > I mean, when I run the code below (Java 1.6.0_13-b03 / Sun JDK 6) the output is: > > Attempting to read a line... > program called inputstream's read(byte[] b, int off, int len) > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > at inputstreamtest.Main.main(Main.java:14) > > And if I look at the source code for StreamDecoder.java [1] I see the > following lines: > 283 int n = in.read(bb.array(), bb.arrayOffset() + pos, rem); > 284 if (n < 0) > 285 return n; > 286 if (n == 0) > 287 throw new IOException("Underlying input stream > returned zero bytes"); > > Which kind of makes sense, because the javadoc for read(byte[] b, int > off, int len) [2] does explicitly say that "If len is zero, then no > bytes are read and 0 is returned; otherwise, there is an attempt to > read at least one byte. If no byte is available because the stream is > at end of file, the value -1 is returned; otherwise, at least one byte > is read and stored into b." > > Is this the problem that you encountered? > > Michael > > [1] http://www.docjar.com/html/api/sun/nio/cs/StreamDecoder.java.html > [2] http://java.sun.com/javase/6/docs/api/java/io/InputStream.html#read(byte[],%20int,%20int) > > > // CODE BEGINS HERE > package inputstreamtest; > > import java.io.BufferedReader; > import java.io.IOException; > import java.io.InputStream; > import java.io.InputStreamReader; > > public class Main { > > public static void main(String[] args) { > BufferedReader in = new BufferedReader(new > InputStreamReader(new FakeInputStream())); > System.out.println("Attempting to read a line..."); > try { > in.readLine(); > } catch (IOException e) { > e.printStackTrace(); > } > } > > private static class FakeInputStream extends InputStream { > @Override > public int read(byte[] b, int off, int len) { > System.out.println("program called inputstream's > read(byte[] b, int off, int len)"); > return 0; > } > > @Override > public int read() throws IOException { > System.out.println("program called inputstream's read()"); > return -1; > } > } > > } > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From cowwoc at bbs.darktech.org Wed May 20 04:45:25 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 06:45:25 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <4A13DF45.7030305@bbs.darktech.org> Kustaa Nyholm wrote: > It is fine. It ain't broken, don't fix it. This is mainly > a documentation issue. When the map and scenery disagree trust > the scenery. This isn't "documentation". It's a specification. The core Java APIs implement it perfectly and expect it to be followed 100% of the time. It is impossible to change it this late in the game. Gili From Kustaa.Nyholm at planmeca.com Wed May 20 06:03:15 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 15:03:15 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A131674.6000906@bbs.darktech.org> Message-ID: > > Guys, I am feeling very frustrated with this whole discussion. I feel your pain as I'm frustrated, not by the discussion which has been conducted in a gentlemanly maner and has entertained me quite a lot, but by people trying to fix what ain't broken. > > 1) There is no doubt that the current implementation breaks the > InputStream API. Well, this is like saying my car is broken because a mouse ate the registration paper (honestly, that happened last winter). There is only a very minor discrepancy between what a few document sentences says and what *useful and practical* functionality the current rxtx/javacomm provides. > A return value of -1 is already mapped to > end-of-stream. For this reason, you *cannot* map the same value to a > timeout. This is basic design-by-contract! I thought we already agreed (talking about read(byte[])) 0 should be returned and AFAIK *is* returned. And this matches the javadoc for CommPort.getInputStream() which says that it return a kind of InputStream where read operations blocks until a timeout occurs OR until any data is available. So it can return even when no data is available. And in that case 0 seems like an appropriate return value. It bends the rules of InputStream a bit, but this is by design, not error. Now, if read() returns -1 in case of timeout this is a dilemma as it does allow differentiation between EOF (whatever it means for serial stream) and timeout. However the 'golden standard', the stream object that javacomm.SerialPort.getInputStream().read(), returns in case of timeout is -1, at least on Windows (just tested it). And we should not brake this compatibility. > > 2) RXTX's implementation does not match javax.comm 100%. > So? Why make it match even less? Most people want compatibility and usability, not semantic / logical correctness at least as far as something as small as serial port API is concerned. Go write your own wrapper if it bother you. > There are > plenty of situations where the two implementations diverge. If there are, please let us know, this is very useful information for any rxtx user so that they can avoid these pitfalls. > I am > frustrated that people want to simultaneously freeze the APIs and fix > issues that *cannot* be fixed purely in the implementation layer. What issues you mean? Off hand I don't recall people asking for fixes that would match your description of "that *cannot* be fixed purely in the implementation layer". Personally, all I've ever wanted from javacomm and rxtx was to be able to access the serial port from Java in platform neutral fashion that allows my code to run on the three major platforms Mac OS X, Linux and Windows. And rxtx delivers just that. > > 3) "Premature optimization is the root of all evil" and yet I see people > complaining that exception handling costs 13 usec. I'm sure you understood that 13 usec was not the point. The point is that exception handling concept has been designed to handle exceptional case which are rare and thus performance of the code when an exception is thrown can be slow. The penalty is not specified but includes creating a new object or several (stack trace) and frequently warned about. Like I said, and I'm sure you understood, at 9600 baud this penalty is not an issue, but in a slower machine (mine was, as stated 2.8 GHz/4GB/1066MHz Core 2 Duo), or different JVM, or JIT not happening (BTW exception handling disturbs JIT) it could be a decade slower. So make it 100 usec and raise baud rate to 1 MBps now merely throwing the exception takes ten times longer than a one character timeout. Many protocols I have programmed have used pauses of less than that to frame messages. IMO it would be serious mistake to use exceptions to handle timeouts. Ever wondered why EOF is signaled with -1 and not an exception... > Java places > emphasizes correctness above performance. If you don't get that you > shouldn't be coding in Java. This is not what I would call parliamentary language. I won't reply. > > More specific replies below... > >> Throwing InterruptedIOException from InputStream.read() is just as >> big sin as it breaks the contract of InterruptedIOException , which >> says that the *thread* that was performing the IO was interrupted. > > A thread getting interrupted is not the same as Thread.interrupt(). Oh yeah? Really? In the context it was used I beg to differ. > My interpretation is that interrupting the operation due to a timeout is a > perfectly legal form of "thread interruption". Even with respect to > Thread.interrupt(), you can't interrupt a thread, only the work it is > executing. > >> Coneceptually I feel throwing an exception is a big sin in a situation >> which is not an error. > > Exceptions refer to "exceptional circumstances" which is not the same > as "errors". By that I mean that the "normally" the method returns > 0-255, but exceptional cases such as timeouts are perfectly legal. But timeout with SerialPort usually is not an exceptional case. But I guess you are fixed to your idea that it is. The important thing however is that it is not for me or you to decide and thus it is not for the API to dictate this. > >> A time out in a serial communication is >> almost always to be excepted since it is used to deal with real, live >> hardware outside the computer > > I disagree. Some application-level protocols don't use timeouts at > all. > Why would your argument be true for serial connections but not sockets? What Sockets and application level protocols have got to do with reading a SerialPort/RS232 port and it's timeouts? > >> So you are advocating adding a new class SerialPortChannel and >> a new method SerialPort.getSerialPortChannel() ? >> >> That would be acceptable in that it would not brake existing code but >> totally unnecessary in my view. I suspect most people turn to rxtx >> as a replacement for javacomm and are only interested in getting the >> job done. And the current API does this with very nicely. I think >> we all have better use for our time than to re-invent a serial port >> API. > > The classic IO api is synchronous whereas NIO channels are > asynchronous. Trying to retrofit timeouts on top of the old APIs will > never be as clean as using NIO which is designed specifically for this > purpose. > You maybe right, but the cure is worse than the disease and the first rule of a good doctor is to "do no harm". What you are concerned about is some semantic details what most of us are concerned with is getting the job done. Here are some more thoughts on using exceptions in case you can be bothered. Quoting from Sun's exception handling tutorial: http://java.sun.com/docs/books/tutorial/essential/exceptions/throwing.html "An Exception indicates that a problem occurred" Now, a timeout, to me, is not a problem, but very often an essential part of the communication protocol. Of course for some in some situations it maybe a problem, but that is not for the (communication) API designer to decide or dictate. To me this spells that timeouts should not throw an exception. Also from the same document: "Here's the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception." Following this guideline would dictate that timeout exception should be a checked exception (because surely almost universally the programmer who enables timeouts (disable by default, remember) can and will handle the timeouts in some reasonable way. *Adding a checked exception toInputStream.reads is not possible.* Again this speaks against throwing an exception in case of timeouts. More in the same vein: http://developer.apple.com/documentation/Performance/Conceptual/CodeSpeed/Ar ticles/TuningJavaCode.html#//apple_ref/doc/uid/TP40002329-DontLinkElementID_ 4 "Exception handling in Java is very slow. ... use exceptions only for truly exceptional cases. Do not use exceptions to indicate simple errors from which your code could otherwise recover. Instead, use them only to indicate abnormal conditions that your code does not know how to handle." cheers Kusti From Kustaa.Nyholm at planmeca.com Wed May 20 06:20:34 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 15:20:34 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A13DDE3.8070703@bbs.darktech.org> Message-ID: > > Not true. Either we follow the InputSteam specification or we define > our own interface. Breaking the specification in this way will trigger > unpredictable bugs. Well bugs are by their very nature unpredictable, what? But seriously who are you to dictate "high road or low road"? Who says we (whoever that 'we' are) must either follow 100% or define our own? If 'we' want to take a middle road we surely can. And I'm all for it. Pursuing 100% clean designs is a fruitless goal and I've got better things to do than keep updating my code base to track an ever changing API in pursuit of an unattainable internal and external purity and correctness. > > Fair enough, but "timeouts in a loop" -- using available() -- don't > break the InputStream specification. So why not use it? If you do not touch the enableTimeout() and enableThreshold() methods the SerialPort.InputStream fulfills the contract to the letter. And if you touch them, it fulfills the commitment that creators of the original API made. > You're supposed to either create your own interface or use NIO for that. > In my view, breaking the superclass contract is always worse than > inconveniencing yourself. Why don't you provide a proof of concept framework of classes and interfaces that are internally and externally consistent for us to scrutinize? I bet it will contain one or two compromises and bending of the rules or be totally out of tune what people need or want to use. cheers Kusti From Steffen.DETTMER at ingenico.com Wed May 20 07:23:40 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 20 May 2009 15:23:40 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A13DDE3.8070703@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> <20090520083008.GH17036@elberon.bln.de.ingenico.com> <4A13DDE3.8070703@bbs.darktech.org> Message-ID: <20090520132339.GB27170@elberon.bln.de.ingenico.com> * cowwoc wrote on Wed, May 20, 2009 at 06:39 -0400: > >>1) There is no doubt that the current implementation breaks the > >>InputStream API. > > > >(which must happen, because InputStream as defined is less usable) > > Not true. Either we follow the InputSteam specification or we define > our own interface. Breaking the specification in this way will trigger > unpredictable bugs. First, I disagree that it is specification because it actually is documentation. A specification would also need to specify how overloaded methods are allowed to change without violating the specification. If javadoc in general would be no documentation but specification obviously no overloaded method could specialise or change any behavior, because as soon as documentation of an overloaded would be needed, it would violate base class specification, in short, no new specification (documentation) could be allowed in any subclass. Theoretically this could be a point (an option to develop a language) but I think it makes not much sense in practice. Also, it often happens that even in specifications there are obvious issues, as soon as everyone does the obvious thing, instead of changing all implementations, the specification is fixed. Or left as it is :) Of course we define an own interface by deriving (implementing) InputStream because specifics will happen. For instance specialised exceptions may be thrown in special new situations not documented (specified) by InputStream. This is what OO is for I think. :) > Actually, the Javadoc for read(byte[]) says that at least one > byte must be read: "If the length of b is zero, then no bytes > are read and 0 is returned; otherwise, there is an attempt to > read at least one byte. If no byte is available because the > stream is at the end of the file, the value -1 is returned; > otherwise, at least one byte is read and stored into b." Strictly speaking, at least for me with my limited foreign language English knowledge, it does not tell what happens if an attempt to read at least one byte was done, no byte was available, the stream is NOT at the end of the file, but still no byte was read. I would accept the point that, strictly speaking, InputStream unconditionally forbids any timeout support (except polling available(), which at least sucks). This actually was my initial point. This prohibition makes no sense and probably was just done by accident (otherwise, docu should tell this) and also is violated if throwing exceptions and also is violated by Java stuff itself. > Fair enough, but "timeouts in a loop" -- using available() -- > don't break the InputStream specification. Yes, and somewhere probably there is some guy who defined InputStream as an Aprils Fool Joke and now cannot sleep because laughing about all those people that poll available() all the time (no delay to gain response time) wasting all CPU resources :-) Anyway, since years InputStream is used and I don't think we can do anything against. I also don't like it, but that's life. If you want a nice language use C++ or Ruby or so ;) SCNR. > >NIO is a bit more BSD socket API style, a step into the direction > >where everything comes from. Next version might take another step > >and reach the goal. Who knows. As far as I know none of the > >issues that lead to NIO (mostly performance and scalability) > >apply to rxtx. > > NIO allows you to select() on a channel with a timeout, which > is the point of contention. Yes, but not if the channel is some InputStream like STDIN, right? Also, as far as I know, you cannot select on own things. So wouldn't work for serial lines or protocols. I think you cannot implement TCP via PPP reasonable and efficiently in (pure) Java, even with NIO as far as I know this is not possible. But there are many things in Java that you cannot implement in Java (even String!). A pitty but otherwise things would be horrible slow. > I'm not sure I understand. I get that you dislike that > InputStream doesn't provide facilities for non-blocking reads > but that is just life. You're supposed to either create your > own interface or use NIO for that. In my view, breaking the > superclass contract is always worse than inconveniencing > yourself. I think, when we would discuss NIO, we would also quickly find sufficient issues with it (I think we had this discussion already) and that we do not (really :)) break the superclass contract (of InputStream). We just add possibility to support timeout (by new method setReceiveTimeout() and overloaded read()). :-) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed May 20 07:40:03 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 20 May 2009 15:40:03 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> Message-ID: <20090520134002.GC27170@elberon.bln.de.ingenico.com> (OT) * Kustaa Nyholm wrote on Wed, May 20, 2009 at 15:03 +0300: > Ever wondered why EOF is signaled with -1 and not an exception... Yeah... I always wonder why Java has so many issues that were already discussed and solved since ages in POSIX or ANSI-C or C++ /before/ java was started. On POSIX reads -1 is error. You call some select(2) before. If select tells ready-for-read and you read EOF, read returns 0 bytes. This is at least a bit intuitive - and seems to work in all cases. Seeing a file descriptor like a class IMHO works. read(fd, ..) could be understood as fd.read(). When looking how great in overall this works I feel deep respect for all the people who invented that :) > > Java places emphasizes correctness above performance. This is definitely wrong. Much of Java Core Tech is uglyDirtyNasty because of performance. For instance you cannot overload String (reasonable). Operator overloading is not possible except for String.operator+ (concatenation). Implicite conversion is possible by Object().toString() but nowhere else. You cannot implement a toLong() and have it be called implicitely. String automatically uses StringBuffer for operations, again a hack you have no chance to copy or influence. You cannot pass scalars like long by reference, you are force to pass them by value. You cannot pass Objects by value, you are forced to pass them by reference. Except your object is e.g. a Long, then it is passed by value. You cannot implement any of that in Java itself. It is Mr. JVM in person :) who knows those hacks and how to workaround / pass by. Also great is Object.clone(). Works without overloading. How does Object.clone() know the members of the child class? Because it knows the structure and hacks it to match. Same for serialisation and deserialisation. Object construction. Why can an Object call a method overloaded in a child class in its constructor? Interesting is what happens: the child class is already `half constructed', i.e. working except member initialisation and its constructor was not run. But a method can be invoked. This is not clean this sucks but anyway. We could continue this quite some time (Inner Class hacks, Generics hacks, forced GC, no RAII support would be next) :-) Honestly, a student would not pass a university test with so much hacking (I hope ;)). oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From michael.erskine at ketech.com Wed May 20 07:45:13 2009 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 20 May 2009 14:45:13 +0100 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0D6BA5.8020209@bbs.darktech.org> References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <06BA3262D918014F9183B66425D5A8D463C3C2E90A@no-sv-03.ketech.local> I wander in to find a gazillion posts about whether RXTX is breaking some rule or other. I don't have time to read and argue the toss over which way of doing something may be more correct. As far as I'm concerned (and, I venture, the other developers in industry) whatever RXTX does _IS_ the right thing. I don't fancy trying to justify the costs that would be incurred in the respecifying, rewriting, and retesting of an absolute ton of SIL2 software. Please, let's not screw things up. Regards, Michael Erskine. From Kustaa.Nyholm at planmeca.com Wed May 20 07:58:12 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 16:58:12 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090520134002.GC27170@elberon.bln.de.ingenico.com> Message-ID: Just to clarify Steffen's mail, this was not my sentence: >>> Java places emphasizes correctness above performance. to which he responded: > > This is definitely wrong. Much of Java Core Tech is > uglyDirtyNasty because of performance. > > Honestly, a student would not pass a university test with so much > hacking (I hope ;)). > and with which I agree. cheers Kusti From Kustaa.Nyholm at planmeca.com Wed May 20 08:13:54 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 17:13:54 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <06BA3262D918014F9183B66425D5A8D463C3C2E90A@no-sv-03.ketech.local> Message-ID: Michael Erskine: > I wander in to find a gazillion posts about whether RXTX is breaking some rule > or other. I don't have time to read and argue the toss over which way of doing > something may be more correct. I've participated in the discussion just for that reason, trying to prevent anyone 'correcting' this API. > > As far as I'm concerned (and, I venture, the other developers in industry) > whatever RXTX does _IS_ the right thing. Indeed! > > I don't fancy trying to justify the costs that would be incurred in the > respecifying, rewriting, and retesting of an absolute ton of SIL2 software. > Hear, hear! > Please, let's not screw things up. Yeah, let's not screw this up. From cowwoc at bbs.darktech.org Wed May 20 08:40:11 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 10:40:11 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090520132339.GB27170@elberon.bln.de.ingenico.com> References: <4A131674.6000906@bbs.darktech.org> <20090520083008.GH17036@elberon.bln.de.ingenico.com> <4A13DDE3.8070703@bbs.darktech.org> <20090520132339.GB27170@elberon.bln.de.ingenico.com> Message-ID: <4A14164B.6040000@bbs.darktech.org> Steffen DETTMER wrote: > First, I disagree that it is specification because it actually is > documentation. A specification would also need to specify how > overloaded methods are allowed to change without violating the > specification. If javadoc in general would be no documentation > but specification obviously no overloaded method could specialise > or change any behavior, because as soon as documentation of an > overloaded would be needed, it would violate base class > specification, That is incorrect. Design by Contract allows subclasses to weaken preconditions, strengthen postconditions and strengthen invariants -- all without violating the superclass specification. > Also, it often happens that even in specifications there are > obvious issues, as soon as everyone does the obvious thing, > instead of changing all implementations, the specification is > fixed. Or left as it is :) As far as I know, this has never been done for core Java classes because doing so would break backwards compatibility. This is discussed at length in the Effective Java book. > Of course we define an own interface by deriving (implementing) > InputStream because specifics will happen. For instance > specialised exceptions may be thrown in special new situations > not documented (specified) by InputStream. This is what OO is for > I think. :) A subclass may not throw any new (checked) exceptions. Doing so would violating the superclass specification. You could always throw a subclass of IOException but that's about it. The reason this only applies to checked exceptions is that all methods throw RuntimeException by default. >> Actually, the Javadoc for read(byte[]) says that at least one >> byte must be read: "If the length of b is zero, then no bytes >> are read and 0 is returned; otherwise, there is an attempt to >> read at least one byte. If no byte is available because the >> stream is at the end of the file, the value -1 is returned; >> otherwise, at least one byte is read and stored into b." > > Strictly speaking, at least for me with my limited foreign > language English knowledge, it does not tell what happens if an > attempt to read at least one byte was done, no byte was > available, the stream is NOT at the end of the file, but still no > byte was read. The sentence above reads "This method blocks until input data is available, end of file is detected, or an exception is thrown." In other words, you must block. > I would accept the point that, strictly speaking, InputStream > unconditionally forbids any timeout support (except polling > available(), which at least sucks). > > This actually was my initial point. This prohibition makes no > sense and probably was just done by accident (otherwise, docu > should tell this) and also is violated if throwing exceptions and > also is violated by Java stuff itself. If a timeout could be said to be a new kind of end-of-stream (with the resulting behavior being absolutely identical) then using -1 might be fine. Unfortunately, this is not the case. End-of-stream indicates that the InputStream will never return bytes ever again. Timeouts violate this guarantee. With respect to exceptions, you are allowed to throw any subclass of IOException for the reasons mentioned in Design by Contract. >> Fair enough, but "timeouts in a loop" -- using available() -- >> don't break the InputStream specification. > > Yes, and somewhere probably there is some guy who defined > InputStream as an Aprils Fool Joke and now cannot sleep because > laughing about all those people that poll available() all the > time (no delay to gain response time) wasting all CPU resources > :-) InputStream works perfectly fine for synchronous reading. If you want asynchronous reading you are supposed to use NIO channels. >> NIO allows you to select() on a channel with a timeout, which >> is the point of contention. > Yes, but not if the channel is some InputStream like STDIN, > right? Also, as far as I know, you cannot select on own things. > So wouldn't work for serial lines or protocols. I don't understand what you mean. You can get a Channel for System.in using java.nio.channels.Channels. > I think you cannot implement TCP via PPP reasonable and > efficiently in (pure) Java, even with NIO as far as I know this > is not possible. But there are many things in Java that you > cannot implement in Java (even String!). You can find TCP/PPP implementations in Java on the web. You don't need them most of the time because the OS provides an implementation for free. > I think, when we would discuss NIO, we would also quickly find > sufficient issues with it (I think we had this discussion > already) and that we do not (really :)) break the superclass > contract (of InputStream). We just add possibility to support > timeout (by new method setReceiveTimeout() and overloaded read()). Again, I suggest you read up on Design by Contract. You will find out exactly why you are not allowed to overload the -1 return code in this way. Gili From cowwoc at bbs.darktech.org Wed May 20 08:46:08 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 10:46:08 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <06BA3262D918014F9183B66425D5A8D463C3C2E90A@no-sv-03.ketech.local> References: <4A0D6BA5.8020209@bbs.darktech.org> <06BA3262D918014F9183B66425D5A8D463C3C2E90A@no-sv-03.ketech.local> Message-ID: <4A1417B0.3040903@bbs.darktech.org> Michael, You have a choice to either break compatibility with old versions of RXTX or break compatibility with all other libraries in existence. Both options suck, but the latter involves breaking even more code. Right now you cannot safely pass RXTX's InputStream into any other library in existence. Gili Michael Erskine wrote: > I wander in to find a gazillion posts about whether RXTX is breaking some rule or other. I don't have time to read and argue the toss over which way of doing something may be more correct. > > As far as I'm concerned (and, I venture, the other developers in industry) whatever RXTX does _IS_ the right thing. > > I don't fancy trying to justify the costs that would be incurred in the respecifying, rewriting, and retesting of an absolute ton of SIL2 software. > > Please, let's not screw things up. > > Regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From johnny.luong at trustcommerce.com Wed May 20 09:55:03 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Wed, 20 May 2009 08:55:03 -0700 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> Message-ID: <4A1427D7.2020906@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Trent Jarvi wrote: | On Tue, 19 May 2009, cowwoc wrote: |>> A time out in a serial communication is |>> almost always to be excepted since it is used to deal with real, live |>> hardware outside the computer |> I disagree. Some application-level protocols don't use timeouts at all. |> Why would your argument be true for serial connections but not sockets? |> | | Hi Gili | | One fundamental difference between sockets, file io and RS232 | communication is that sockets and file systems provide error handling. | If a packet is lost, it is resent without the java API knowing about it. | | RS232 is actually an electrical signal standard. Serial communication | exposes a UART without any meaningful error handling and cludgy error | reporting. | | Given the above, ignoring timeouts is not really a valid rxtx level | option. We could have a new option/method that allows you to get an | InputStream or Channel that behaves as you wish. | | If we change the InputStream returned by getInputStream(), that would | be change in the API (version 3.0) that forks our userbase. | | So I guess my question is whether or not you are trying to change the | object returned by getInputStream or just looking for a means to get a | different object you would like to define be returned. | | The later is far easier to accommodate. | | -- | Trent Jarvi | tjarvi at qbang.org | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Trent, For sockets, I'm not so sure there is really any guarantees short of actually monitoring it externally. For example, write() in outputstream doesn't return any value whatsoever -- you might get an exception but in the worse case, it just tells you something bad happened and in the best case, you might be able to catch some implementation specific exception. ~ The same could apply to files too but the magnitude of failure there are significantly lower. But this is sort of a digression... My thinking is that we just sort of keep the interface so that we don't disrupt people who use the methods (our software actually polls from the serial port version of the InputStream/OutputStream as a side effect of the quirkyness involved with the timeout -- this is because the USB-serial thing we had to work with really sucks) but add an additional interface similar to what is SocketChannel and proceed from there. There is a lot of work involved in it though and as it has been pointed out by others, maybe most can live with the hacks involved in the current implementation. Best, Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoUJ9cACgkQnQTBLXttTeVYlQCfcvIHMh1W1kcna5vUtg20dWWK flMAn2WZk03PSgYT1KkHMLp8TlLRtcxn =YeMI -----END PGP SIGNATURE----- From michaeltandy at googlemail.com Wed May 20 09:57:36 2009 From: michaeltandy at googlemail.com (Michael Tandy) Date: Wed, 20 May 2009 16:57:36 +0100 Subject: [Rxtx] Rxtx native library loading In-Reply-To: References: <302aa0340905190733r4009e394v335b3ef47d84ffb5@mail.gmail.com> Message-ID: <302aa0340905200857v53642f58je6932c3315b8a30d@mail.gmail.com> There's also a bug in my code; it worked fine swapping between my Windows machine and my 64-bit Linux machine, but trying to run the 64-bit library on my 32-bit Linux laptop (obviously) doesn't work. So, it needs to detect more architectures and handle them more cleverly :) Still, if your next release will do that, I guess I don't have to fix my code :) Thanks Michael 2009/5/20 Trent Jarvi : > > Hi Michael, > > We will be putting a patch like yours in as soon as we release 2.2. ?The > release was going to be mothers day but I got caught up :) ?I hope to do it > next weekend. ?After that we will be looking at web installs which overlaps > with your solution. > > -- > Trent Jarvi > tjarvi at qbang.org > From cowwoc at bbs.darktech.org Wed May 20 10:04:32 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 12:04:32 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A1427D7.2020906@trustcommerce.com> References: <4A131674.6000906@bbs.darktech.org> <4A1427D7.2020906@trustcommerce.com> Message-ID: <4A142A10.1090302@bbs.darktech.org> Johnny Luong wrote: > My thinking is that we just sort of keep the interface so that we don't > disrupt people who use the methods (our software actually polls from the > serial port version of the InputStream/OutputStream as a side effect of > the quirkyness involved with the timeout -- this is because the > USB-serial thing we had to work with really sucks) but add an additional > interface similar to what is SocketChannel and proceed from there. We could also deprecate getInputStream() in favor of another method that returns a fixed implementation. This will allow existing code to keep on working while providing a migration route for RXTX 3.0. Gili From jerrypedersen at telus.net Wed May 20 10:10:00 2009 From: jerrypedersen at telus.net (Jerry Pedersen) Date: Wed, 20 May 2009 09:10:00 -0700 Subject: [Rxtx] 38400 Baud - UnsupportedCommOperationexception: Invalid Parameter Message-ID: <4A142B58.4050909@telus.net> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090520/0ac89fb9/attachment.html From bill7007 at gmail.com Wed May 20 11:20:13 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Wed, 20 May 2009 13:20:13 -0400 Subject: [Rxtx] 38400 Baud - UnsupportedCommOperationexception: Invalid Parameter In-Reply-To: <4A142B58.4050909@telus.net> References: <4A142B58.4050909@telus.net> Message-ID: Hi Jerry, You might check out: [Rxtx] Baud rate fixes in 2.2pre2 breaks 38400 on some Linux devices It has a link to a patch on 2.2pre that got me around a similar problem. +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090520/046aa29d/attachment.html From Kustaa.Nyholm at planmeca.com Wed May 20 12:23:41 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 21:23:41 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A1417B0.3040903@bbs.darktech.org> References: <4A0D6BA5.8020209@bbs.darktech.org> <06BA3262D918014F9183B66425D5A8D463C3C2E90A@no-sv-03.ketech.local>, <4A1417B0.3040903@bbs.darktech.org> Message-ID: <5D23E5B41156B646B2E1A7C2BBA916F317119151AF@SRVFIHKIEXB01.pmgroup.local> Gili wrote: >You have a choice to either break compatibility with old versions of >RXTX or break compatibility with all other libraries in existence. Both >options suck, but the latter involves breaking even more code. Or, the third option, leave it well alone! Keep it compatible existing code that is actually using rxtx instead of just worrying about it being correct to a T. Use it as the creators meant it to be used. Stop worrying about this. > Right now you cannot safely pass RXTX's InputStream into any other >library in existence. Now that is blatantly untrue. If timeouts are not enable you can pass it safely to any library. When timeouts are enabled *some* libraries will not work, some will. If you worry or encounter such a situation you can then do some wrapper magic. But for pete's sake, let us not disturb the happy life of rxtx users with well intentioned but misguided zealozy. I wonder too how often SerialPort input stream is passed to *any* library? I certainly haven't done that ever. The way I vision people are using serial port is to talk directly to it doing most if not all of the protocol handling with custom code, not with a library. If pass it (the input stream) to a library that chokes on read returning 0 it is rather your fault for not reading what the javadoc for SerialPort.getInputStream says! cheers Kusti From tjarvi at qbang.org Wed May 20 17:18:37 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 May 2009 17:18:37 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A142A10.1090302@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> <4A1427D7.2020906@trustcommerce.com> <4A142A10.1090302@bbs.darktech.org> Message-ID: On Wed, 20 May 2009, cowwoc wrote: > Johnny Luong wrote: >> My thinking is that we just sort of keep the interface so that we don't >> disrupt people who use the methods (our software actually polls from the >> serial port version of the InputStream/OutputStream as a side effect of >> the quirkyness involved with the timeout -- this is because the >> USB-serial thing we had to work with really sucks) but add an additional >> interface similar to what is SocketChannel and proceed from there. > > We could also deprecate getInputStream() in favor of another method > that returns a fixed implementation. This will allow existing code to > keep on working while providing a migration route for RXTX 3.0. > Hi Gili, Good. I think it is time to see the method and InputStream. From there, we can discuss options in 3.0. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Wed May 20 18:49:50 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 20:49:50 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> <4A1427D7.2020906@trustcommerce.com> <4A142A10.1090302@bbs.darktech.org> Message-ID: <4A14A52E.7080701@bbs.darktech.org> Trent Jarvi wrote: > Good. > > I think it is time to see the method and InputStream. From there, we > can discuss options in 3.0. I propose the following: 1) add "CommPortChannel getChannel()" 2) deprecate getInputStream() and enableReceiveTimeout() in favor of getChannel() 3) getChannel() will return a class that implements the same interfaces as SocketChannel. It will allow both blocking and non-blocking I/O operations. 4) In RXTX 3.0 getInputStream() will return an InputStream that always blocks on reads and the method will be undeprecated. Gili From tjarvi at qbang.org Wed May 20 19:27:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 May 2009 19:27:50 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A14A52E.7080701@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> <4A1427D7.2020906@trustcommerce.com> <4A142A10.1090302@bbs.darktech.org> <4A14A52E.7080701@bbs.darktech.org> Message-ID: On Wed, 20 May 2009, cowwoc wrote: > Trent Jarvi wrote: >> Good. >> >> I think it is time to see the method and InputStream. From there, we can >> discuss options in 3.0. > > I propose the following: > > 1) add "CommPortChannel getChannel()" > 2) deprecate getInputStream() and enableReceiveTimeout() in favor of > getChannel() > 3) getChannel() will return a class that implements the same interfaces as > SocketChannel. It will allow both blocking and non-blocking I/O operations. > 4) In RXTX 3.0 getInputStream() will return an InputStream that always blocks > on reads and the method will be undeprecated. > Hi Gili, RXTX 3.0 would be the soonest we would start any deprecation if it is agreed upon. So far, I don't think there is near enough buy in. But you can have getChannel now. If it is obviously a right solution, you may see people reconsider their opinions. Timeouts wont go away or be deprecated but they could throw unsupported io exceptions for the life of the inputstream returned by getChannel for obvious reasons. Let people try it and give feedback. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Thu May 21 01:19:05 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 21 May 2009 10:19:05 +0300 Subject: [Rxtx] InputStream timeouts Message-ID: <5D23E5B41156B646B2E1A7C2BBA916F317119151B4@SRVFIHKIEXB01.pmgroup.local> Hi Gili, please don't start patronizing. I've been around OO and Design by Contract from around 1986 starting by implementing our own Smalltalk environment. By then I had been writing software for ten years. It is not that I don't understand what you are saying. It is just that I'm not (any more ?!) an OO or DbC zealot. In real world most concepts seem to break down when applied over too wide field. Newtons laws are fine until you get to quantum level. OO is great, but at least so far, it seems that making everything (think integers) objects was a mistake in Smalltalk. You maybe right on the theoretical level, but who cares? Who are you to impose *your* standards on the rest of us? *Every good desing is a compromize.* In this instance I'm 100% sure that the designers of javacomm were well aware of the issues you are complaining about and considered these and many other issues. And their compromise is what we have today.It would belittling them to think otherwise. And to me, even if I think I see where you are coming from, the compromise seem almost perfect for the given problem. To me it is very natural and works almost perfectly despite (or because ?) of the little bending of the rules. Like Steffen(?) wrote here earlier : that (compromise to make it work) is Java all over. And I firmly believe that that is what made Java a success, just like C. Not the prettiest girls in town but very popular... cheers Kusti ________________________________________ From: cowwoc [cowwoc at bbs.darktech.org] Sent: Wednesday, May 20, 2009 9:42 PM To: Kustaa Nyholm Subject: Re: [Rxtx] InputStream timeouts Do me a favor and let me know once you read about Design by Contract. Only then will you be able to understand why RXTX cannot redefine how InputStream works. If subclasses are allowed to modify the contract in an arbitrary manner it defeats the entire concept of Class Inheritance and formal Interfaces. Gili Kustaa Nyholm wrote: > Gili wrote: > >> You have a choice to either break compatibility with old versions of >> RXTX or break compatibility with all other libraries in existence. Both >> options suck, but the latter involves breaking even more code. > > Or, the third option, leave it well alone! Keep it compatible existing code > that is actually using rxtx instead of just worrying about it being correct > to a T. Use it as the creators meant it to be used. Stop worrying about > this. > > >> Right now you cannot safely pass RXTX's InputStream into any other >> library in existence. > > Now that is blatantly untrue. If timeouts are not enable you can pass > it safely to any library. When timeouts are enabled *some* libraries will > not work, some will. If you worry or encounter such a situation you > can then do some wrapper magic. But for pete's sake, let us not disturb > the happy life of rxtx users with well intentioned but misguided zealozy. > > I wonder too how often SerialPort input stream is passed to *any* library? > > I certainly haven't done that ever. > > The way I vision people are using serial port is to talk directly to it > doing most if not all of the protocol handling with custom code, > not with a library. If pass it (the input stream) to a library that chokes on > read returning 0 it is rather your fault for not reading what > the javadoc for SerialPort.getInputStream says! > > cheers Kusti > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Kustaa.Nyholm at planmeca.com Thu May 21 01:20:42 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 21 May 2009 10:20:42 +0300 Subject: [Rxtx] InputStream timeouts Message-ID: <5D23E5B41156B646B2E1A7C2BBA916F317119151B5@SRVFIHKIEXB01.pmgroup.local> Gili wrote: >You have a choice to either break compatibility with old versions of >RXTX or break compatibility with all other libraries in existence. Both >options suck, but the latter involves breaking even more code. Or, the third option, leave it well alone! Keep it compatible existing code that is actually using rxtx instead of just worrying about it being correct to a T. Use it as the creators meant it to be used. Stop worrying about this. > Right now you cannot safely pass RXTX's InputStream into any other >library in existence. Now that is blatantly untrue. If timeouts are not enable you can pass it safely to any library. When timeouts are enabled *some* libraries will not work, some will. If you worry or encounter such a situation you can then do some wrapper magic. But for pete's sake, let us not disturb the happy life of rxtx users with well intentioned but misguided zealozy. I wonder too how often SerialPort input stream is passed to *any* library? I certainly haven't done that ever. The way I vision people are using serial port is to talk directly to it doing most if not all of the protocol handling with custom code, not with a library. If pass it (the input stream) to a library that chokes on read returning 0 it is rather your fault for not reading what the javadoc for SerialPort.getInputStream says! cheers Kusti From Kustaa.Nyholm at planmeca.com Thu May 21 01:49:36 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 21 May 2009 10:49:36 +0300 Subject: [Rxtx] InputStream timeouts - opinions on breaking compatibility? Message-ID: <5D23E5B41156B646B2E1A7C2BBA916F317119151B6@SRVFIHKIEXB01.pmgroup.local> Hi, changed the subject line a bit because I suspect most people have tuned out of this discussion and yet I feel that it is the very people who's input is needed. A month or so ago a lot of people chimed in by telling *what* they do with rxtx, now I would really be interesting to know *how* people are using rxtx? More specifically and relevant to this discussion: 1) are timeouts used? 2) how are they handled? 3) are SerialPort InputStreams passed to library functions? 4) have there been problems (in 3 above)? 5) how would you feel if you would need to rework your code to work with the 'improved' API? The proposal we have (by Gili) is: > 1) add "CommPortChannel getChannel()" This I do not mind so much as I do not need to touch my code. > 2) deprecate getInputStream() and enableReceiveTimeout() in favor of > getChannel() This I object to very much. One of my coding 'rules' say do-not-use-deprecated methods. An other rule says that my compiles-should-be-clean, so this would need me to change my code. Also, this is imposing and force feeding things to people who can't appreciate the beauty of the 'improvements' and are against them. > 3) getChannel() will return a class that implements the same interfaces as > SocketChannel. It will allow both blocking and non-blocking I/O operations. As I will not be using that (getChannel()) I don't care so much, but I bet this will be a new can worms having just the same sort of issues and compromises as we have been discussing here. But it would really be educational and fun to see proposers eat their own dog meat, so yes, let's do this! > 4) In RXTX 3.0 getInputStream() will return an InputStream that always blocks > on reads and the method will be undeprecated. > Just great, this is the top, I'm totally against this. Not only did (2) above require me to rework my code but now in phase two I would need to rework my code again to comply with yet another API change. There has to be better things in life and coding than tracking ever changing APIs! I'm involved in several projects ranging from a few thousand lines to several thousand hand written classes. Javacomm and rxtx play a small but crucial part in these. I would very much like to spend time on improving the applications instead of tracking changes in different APIs (not limited to rxtx). Especially changes that IMO only bring internal beauty . Our current code works and has been debugged to with the current API design, no compelling reason has been put forward to change the API and throw away the (albeit not so big) investment in learning to use the current API and making our code to work with it. All I care is that I have a cross platform serial port API that is stable and works as advertised, and which I do not have to implement and test on all the platforms. So far rxtx has been just wonderful, let's keep it that way. my 2 snt worth, cheers Kusti From michaeltandy at googlemail.com Thu May 21 05:48:44 2009 From: michaeltandy at googlemail.com (Michael Tandy) Date: Thu, 21 May 2009 12:48:44 +0100 Subject: [Rxtx] Buffer overflow caused by fhs_lock error message Message-ID: <302aa0340905210448v46b7ee61j58787b10500411b@mail.gmail.com> When, on Linux, one attempts to open a device such as /dev/ttyUSB71 and the device is locked, Java crashes with this error message: *** buffer overflow detected ***: java terminated ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7ead6d8] /lib/tls/i686/cmov/libc.so.6[0xb7eab800] /lib/tls/i686/cmov/libc.so.6[0xb7eaaef8] /lib/tls/i686/cmov/libc.so.6(_IO_default_xsputn+0xc8)[0xb7e20a78] /lib/tls/i686/cmov/libc.so.6(_IO_vfprintf+0x6f3)[0xb7df30b3] /lib/tls/i686/cmov/libc.so.6(__vsprintf_chk+0xa4)[0xb7eaafa4] /lib/tls/i686/cmov/libc.so.6(__sprintf_chk+0x2d)[0xb7eaaeed] /home/michael/Documents/asdf/lib/librxtxSerial.so(fhs_lock+0x1c2)[0xb4b82cf2] /home/michael/Documents/asdf/lib/librxtxSerial.so(Java_gnu_io_RXTXCommDriver_testRead+0x80)[0xb4b838a0] This is caused because trying to sprintf the error message, the device name, the error description, the newline and then null terminate the string overflows the 80 characters allocated. The problem code seems to be: char message[80]; sprintf( message,"RXTX fhs_lock() Error: creating lock file: %s: %s\n", file, strerror(errno) ); A switch to the buffer-overflow-proof snprintf function fixes the problem by truncating the error message if it exceeds 79 characters: char message[80]; snprintf( message, 80, "RXTX fhs_lock() Error: creating lock file: %s: %s\n", file, strerror(errno) ); A patch is attached to apply this fix - although there might be other bugs of this class in rxtx; it might be worth applying this fix anywhere sprintf is currently used. Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: overflowpatch.diff Type: application/octet-stream Size: 1133 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090521/3a487d21/attachment.obj From luis.moreira at ntlworld.com Sat May 2 00:39:04 2009 From: luis.moreira at ntlworld.com (luis.moreira at ntlworld.com) Date: Sat, 2 May 2009 7:39:04 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Hi Travis, The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. The issues I still have is the errors after that. Do you have any idea what can be causing this errors? _______________________________________________________________________________ conftest.c: In function 'main': conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) conftest.c:8: error: (Each undeclared identifier is reported only once conftest.c:8: error: for each function it appears in.) conftest.c:8: error: expected ')' before string constant conftest.c:8: warning: format not a string literal and no format arguments ./configure: line 21462: ./conftest: No such file or directory ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands ------------------------------------------------------------------------------- I don't know what happened to my previous post, it as not showed up in the list. Best Regards Luis From tjarvi at qbang.org Sat May 2 07:30:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 07:30:04 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> References: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Message-ID: On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > Hi Travis, > The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. > The issues I still have is the errors after that. Do you have any idea what can be causing this errors? > > _______________________________________________________________________________ > conftest.c: In function 'main': > conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) > conftest.c:8: error: (Each undeclared identifier is reported only once > conftest.c:8: error: for each function it appears in.) > conftest.c:8: error: expected ')' before string constant > conftest.c:8: warning: format not a string literal and no format arguments > ./configure: line 21462: ./conftest: No such file or directory > ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: config.h is unchanged > config.status: executing depfiles commands > ------------------------------------------------------------------------------- > > This was corrected in CVS. I think you can just do the following in the top directory: cvs login: (pw is mousy) cvs update That will get the current fixes. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sat May 2 16:14:50 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sat, 02 May 2009 23:14:50 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FCC5DA.6000700@ntlworld.com> Trent Jarvi wrote: > > > On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > >> Hi Travis, >> The problem with the Makefile is not a problem,When I run ./configure >> I make a new Makefile with the same data in it, hence what I just >> modified is removed. >> The issues I still have is the errors after that. Do you have any >> idea what can be causing this errors? >> >> _______________________________________________________________________________ >> >> conftest.c: In function 'main': >> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >> function) >> conftest.c:8: error: (Each undeclared identifier is reported only once >> conftest.c:8: error: for each function it appears in.) >> conftest.c:8: error: expected ')' before string constant >> conftest.c:8: warning: format not a string literal and no format >> arguments >> ./configure: line 21462: ./conftest: No such file or directory >> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >> expected >> configure: creating ./config.status >> config.status: creating Makefile >> config.status: creating config.h >> config.status: config.h is unchanged >> config.status: executing depfiles commands >> ------------------------------------------------------------------------------- >> >> >> > > This was corrected in CVS. I think you can just do the following in > the top directory: > > cvs login: (pw is mousy) > cvs update > > That will get the current fixes. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, apologies for the mix-up of your name. I managed to get further on by updating CVS, the configure command gets to the end without any errors, it still warns me that it is confused about where to find the jni_md.h but I just edited the Makefile and sorted that out. I then run make, with no parameters following the instructions on the Wiki, but that generated a few more errors: ----------------------------------------------------------------------------------------------------------------------- gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. -I/usr/lib/jvm/java-6-openjdk/include /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' undeclared (first use in this function) /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared identifier is reported only once /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each function it appears in.) libtool: link: `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 ----------------------------------------------------------------------------------------------------------------------- Another question I have is, in which folder will the .so files be placed after make finishes? thank you very much for your help. Best Regards Luis From tjarvi at qbang.org Sat May 2 19:27:08 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 19:27:08 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FCC5DA.6000700@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> Message-ID: On Sat, 2 May 2009, Luis Moreira wrote: > Trent Jarvi wrote: >> >> >> On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: >> >>> Hi Travis, >>> The problem with the Makefile is not a problem,When I run ./configure >>> I make a new Makefile with the same data in it, hence what I just >>> modified is removed. >>> The issues I still have is the errors after that. Do you have any >>> idea what can be causing this errors? >>> >>> _______________________________________________________________________________ >>> >>> conftest.c: In function 'main': >>> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >>> function) >>> conftest.c:8: error: (Each undeclared identifier is reported only once >>> conftest.c:8: error: for each function it appears in.) >>> conftest.c:8: error: expected ')' before string constant >>> conftest.c:8: warning: format not a string literal and no format >>> arguments >>> ./configure: line 21462: ./conftest: No such file or directory >>> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >>> expected >>> configure: creating ./config.status >>> config.status: creating Makefile >>> config.status: creating config.h >>> config.status: config.h is unchanged >>> config.status: executing depfiles commands >>> ------------------------------------------------------------------------------- >>> >>> >>> >> >> This was corrected in CVS. I think you can just do the following in >> the top directory: >> >> cvs login: (pw is mousy) >> cvs update >> >> That will get the current fixes. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > apologies for the mix-up of your name. > I managed to get further on by updating CVS, the configure command gets > to the end without any errors, it still warns me that it is confused > about where to find the jni_md.h but I just edited the Makefile and > sorted that out. > I then run make, with no parameters following the instructions on the > Wiki, but that generated a few more errors: > ----------------------------------------------------------------------------------------------------------------------- > > gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. > -I/usr/lib/jvm/java-6-openjdk/include > /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE > -D_BSD_SOURCE -D__need_timespec -c > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o > /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' > undeclared (first use in this function) > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared > identifier is reported only once > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each > function it appears in.) > libtool: link: > `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a > valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 > ----------------------------------------------------------------------------------------------------------------------- > > Another question I have is, in which folder will the .so files be placed > after make finishes? > > thank you very much for your help. > Ah when you do cvs update pass the -Pd option cvs update -Pd Also, when you run configure, use --disable-PRINTER to only build the serial support. It will make things easier. --disable-LOCKFILES will also be easier to get going until you want to learn about how to prevent multiple applications from reading the same serial port. The link for debugging will describe where the files go. By default, it will install in the JRE/JDK under jre/lib/ext (the jar file) jre/lib/i386 (the .so file) Those are on the proper paths when you use the sun or ibm jdk. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sun May 3 01:30:43 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sun, 03 May 2009 08:30:43 +0100 Subject: [Rxtx] First use of RXTX package In-Reply-To: References: <49FCC5DA.6000700@ntlworld.com> Message-ID: <49FD4823.5080204@ntlworld.com> Ah > > when you do cvs update pass the -Pd option > > cvs update -Pd > > Also, when you run configure, use --disable-PRINTER to only build the > serial support. It will make things easier. --disable-LOCKFILES will > also be easier to get going until you want to learn about how to > prevent multiple applications from reading the same serial port. > > The link for debugging will describe where the files go. By default, > it will install in the JRE/JDK under > > jre/lib/ext (the jar file) > jre/lib/i386 (the .so file) > > Those are on the proper paths when you use the sun or ibm jdk. > > http://rxtx.qbang.org/wiki/index.php/Trouble_shooting > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, It as done it! I think this instructions you gave me should be on the Wiki, I can write them for you if you like. Also on the Wiki when you describe the three methods of installing the RxTx package it is confusing because as far as I can see, you always have to do method 1 or the .so files will not be generated(is this correct?). Then you can if you like change the location with method 1 & 2. Is it possible to modify the .la file to point to different directories for installation and then you can decide where to place the files? In a way I have learned quite a lot about Linux by having to struggle, with your help, to find solutions to the problems I encountered (I am still very new to Linux), but maybe we need to log these problems somewhere to make it less of a struggle for others like me. I have used the PortLister example to test it and it came up with my USB to dual Serial adaptor Ports. I will now explore the RxTx package, before I tackle the windows installation, I will let you know of my experience. Thank you for all your Help. Best Regards Luis From tjarvi at qbang.org Sun May 3 10:37:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 3 May 2009 10:37:50 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FD4823.5080204@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> <49FD4823.5080204@ntlworld.com> Message-ID: On Sun, 3 May 2009, Luis Moreira wrote: > Ah >> >> when you do cvs update pass the -Pd option >> >> cvs update -Pd >> >> Also, when you run configure, use --disable-PRINTER to only build the >> serial support. It will make things easier. --disable-LOCKFILES will >> also be easier to get going until you want to learn about how to >> prevent multiple applications from reading the same serial port. >> >> The link for debugging will describe where the files go. By default, >> it will install in the JRE/JDK under >> >> jre/lib/ext (the jar file) >> jre/lib/i386 (the .so file) >> >> Those are on the proper paths when you use the sun or ibm jdk. >> >> http://rxtx.qbang.org/wiki/index.php/Trouble_shooting >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > It as done it! > I think this instructions you gave me should be on the Wiki, I can write > them for you if you like. Also on the Wiki when you describe the three > methods of installing the RxTx package it is confusing because as far > as I can see, you always have to do method 1 or the .so files will not > be generated(is this correct?). Then you can if you like change the > location with method 1 & 2. Is it possible to modify the .la file to > point to different directories for installation and then you can decide > where to place the files? > In a way I have learned quite a lot about Linux by having to struggle, > with your help, to find solutions to the problems I encountered (I am > still very new to Linux), but maybe we need to log these problems > somewhere to make it less of a struggle for others like me. > > I have used the PortLister example to test it and it came up with my USB > to dual Serial adaptor Ports. > > I will now explore the RxTx package, before I tackle the windows > installation, I will let you know of my experience. > > Thank you for all your Help. > Hi Luis, The locations suggested for first time configuration could be documented in a new wiki page explaining that this is not the recommended general workflow but does help new users that are not worried about having rxtx installed into the JRE. For a professional environment, the user would want to follow the workflow currently on the wiki and keep their JRE clean. Often the user will not be able to add libraries to the JRE and will need to use their home directory or a sandbox. Feel free to add information to the wiki. I'd suggest creating comment in the current page and have the comment link to what worked for you as a first time user new to Linux. You can create a new page with your comments. In the long term, we will be working on an autoinstaller that works over the web. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Mon May 4 09:15:40 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Mon, 04 May 2009 16:15:40 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FF069C.8040406@ntlworld.com> Hi Trent, I have now installed the package on my 64 bit machine and when I run my program I get errors on the attachment. I know it as something to do with the architecture of my system but I can no figure out how to fix it. I have built it from source again, I did not transfer the files from machine to machine. can you please put me in the right direction. Thank you very much for your help. Best Regards Luis -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshoot.png Type: image/png Size: 25753 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090504/141ab5dc/attachment-0018.png From johnny.luong at trustcommerce.com Mon May 4 11:57:08 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 04 May 2009 10:57:08 -0700 Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FF069C.8040406@ntlworld.com> References: <49FF069C.8040406@ntlworld.com> Message-ID: <49FF2C74.90805@trustcommerce.com> Luis Moreira wrote: > Hi Trent, > I have now installed the package on my 64 bit machine and when I run my > program I get errors on the attachment. I know it as something to do > with the architecture of my system but I can no figure out how to fix > it. I have built it from source again, I did not transfer the files from > machine to machine. > can you please put me in the right direction. > Thank you very much for your help. > Best Regards > Luis > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Hi, Does running it on a 64-bit JVM help? Your host environment might be building objects for a 64-bit environment unless you did a cross-compile... -- you can find out by doing something like the following: johnny at spike:~$ java -version java version "1.6.0_0" OpenJDK Runtime Environment (build 1.6.0_0-b11) OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode) johnny at spike:~$ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) -Johnny From huangdongkai at gmail.com Wed May 6 11:06:06 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 01:06:06 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. Message-ID: Dear all, I recompile the rxtxSerial source code by MinGW32 and compile success. But when I run my Application which use rxtxSerial.dll to communicate with serial port, a runtime exception happened and application crash. I have no idea why it can not work, beacuse i have not change any source code of rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I have missed when compile the source code on Window NT? Here below is the output error massage. # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, tid=1360 # # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing windows-x86) # Problematic frame: # V [jvm.dll+0x1b6824] # # An error report file with more information is saved as: # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/32c1e699/attachment-0016.html From tjarvi at qbang.org Wed May 6 20:04:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 May 2009 20:04:10 -0600 (MDT) Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: On Thu, 7 May 2009, dongkai huang wrote: > Dear all, > ????? I recompile the rxtxSerial source code by MinGW32 and compile success. > But when I run my Application which use rxtxSerial.dll to communicate with > serial port, a runtime exception happened and application crash.? I have no > idea why it can not work, beacuse i have not change any source code of > rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I > have missed when compile the source code on Window NT? Here below is the > output error massage. > # > # An unexpected error has been detected by Java Runtime Environment: > # > #? EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, > tid=1360 > # > # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing > windows-x86) > > # Problematic frame: > # V? [jvm.dll+0x1b6824] > # > # An error report file with more information is saved as: > # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log > # > # If you would like to submit a bug report, please visit: > #?? http://java.sun.com/webapps/bugreport/crash.jsp > # > > > Hi Dongkai Could you explain how you compiled rxtx with mingw? Did you run configure? Was the compiler native or a cross compiler (like compiling on Linux for Windows)? Is the crash happening when you first open the port or is it happening randomly later on? -- Trent Jarvi tjarvi at qbang.org From huangdongkai at gmail.com Wed May 6 20:48:56 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 10:48:56 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Hi Trent, I was followed the step on INSTALL file, did not run the configure, I used the Makefile.mingw32 which include on the source code package, and only change some path( jdk home path etc.). And I use the native compiler on Windows. The crash happened on I call the getPortIdentifiers() every time. On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Dear all, >> I recompile the rxtxSerial source code by MinGW32 and compile >> success. >> But when I run my Application which use rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and application crash. I have >> no >> idea why it can not work, beacuse i have not change any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing >> I >> have missed when compile the source code on Window NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is saved as: >> # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> > Hi Dongkai > > Could you explain how you compiled rxtx with mingw? Did you run configure? > Was the compiler native or a cross compiler (like compiling on Linux for > Windows)? > > Is the crash happening when you first open the port or is it happening > randomly later on? > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/733eded5/attachment-0016.html From m.j.tandy at warwick.ac.uk Thu May 7 10:39:12 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 7 May 2009 17:39:12 +0100 Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. Message-ID: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> I've encountered a bug in how XON/XOFF are handled on Windows. The symptoms were: 1. XON/XOFF from device to PC did not stop transmission. 2. XON/XOFF characters were present in data read from serial port input stream, when it was expected that they would be stripped out. 3. Investigation with SysInternals PortMon revealed the following configuration when using rxtx: 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 while HyperTerminal, which did not have the same problems as me, produced the following: 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 In other words, the problem is that, in addition to being told to use XON/XOFF flow control, the computer has to explicitly be told which characters to use for 'XON' and 'XOFF'. This part of the configuration was being missed out. I got the latest rxtx source from CVS, and identified the problem as an omission in the 'init_termios' function of 'termios.c', which configures the unix/termios 'c_cc' (control characters) data structure - but omits to configure the VSTART and VSTOP control characters. Later, the termios c_cc data structure is translated (by termios_to_DCB) into a data structure named 'DCB', which is passed to the windows serial port configuration interface. By adding two lines defining the standard XON/XOFF characters to the function init_termios, the bug is fixed. A patch doing this is attached. Thanks, Michael Tandy -------------- next part -------------- A non-text attachment was scrubbed... Name: xon-xoff.diff Type: application/octet-stream Size: 667 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/159c0dcc/attachment-0015.obj From tjarvi at qbang.org Thu May 7 17:57:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 May 2009 17:57:28 -0600 (MDT) Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. In-Reply-To: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> References: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> Message-ID: On Thu, 7 May 2009, Michael Tandy wrote: > I've encountered a bug in how XON/XOFF are handled on Windows. > > The symptoms were: > 1. XON/XOFF from device to PC did not stop transmission. > 2. XON/XOFF characters were present in data read from serial port > input stream, when it was expected that they would be stripped out. > 3. Investigation with SysInternals PortMon revealed the following > configuration when using rxtx: > > 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 > BRK:0 EVT:a XON:0 XOFF:0 > > while HyperTerminal, which did not have the same problems as me, > produced the following: > > 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 > > In other words, the problem is that, in addition to being told to use > XON/XOFF flow control, the computer has to explicitly be told which > characters to use for 'XON' and 'XOFF'. This part of the configuration > was being missed out. > > I got the latest rxtx source from CVS, and identified the problem as > an omission in the 'init_termios' function of 'termios.c', which > configures the unix/termios 'c_cc' (control characters) data structure > - but omits to configure the VSTART and VSTOP control characters. > Later, the termios c_cc data structure is translated (by > termios_to_DCB) into a data structure named 'DCB', which is passed to > the windows serial port configuration interface. > > By adding two lines defining the standard XON/XOFF characters to the > function init_termios, the bug is fixed. A patch doing this is > attached. > Thanks Michael, Good timing. I plan on releasing rxtx-2.2 this coming Sunday. -- Trent Jarvi tjarvi at qbang.org From wjr at weru.ksu.edu Fri May 8 11:38:29 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Fri, 08 May 2009 12:38:29 -0500 Subject: [Rxtx] swing jfilechooser lockup Message-ID: <4A046E15.6010907@weru.ksu.edu> Hi, I wrote a small swing app to download images from an industrial camera. I used the two way serial sample code as a starting point. The app works fine EXCEPT for a call to jfilechooser. After I open the comm port and then try to change the output directory or log file, the jfilechooser winds up trying to unpark (note, parking is not something I'm really familiar with) and doesn't. If I try to change the file or directory before I start the comm port, it works. If I click on menu items that don't call jfilechooser, everything is OK. If I try closing the comm port and then try to create a jfilechooser, it locks up. There is obviously some sort of deadlock here because the awt thread starts waiting on something but it's not clear what. I haven't gone thru the rxtx code yet because it's not in the file structure that netbeans wants for debugging purposes. However, debugging code that I don't have a clear idea of what it is supposed to do is not my idea of a good time. Does anyone have any ideas on what is going on here? Thanks, wjr From Bob_Jacobsen at lbl.gov Fri May 8 14:48:25 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Fri, 8 May 2009 13:48:25 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A046E15.6010907@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> Message-ID: At 12:38 PM -0500 5/8/09, Bill Rust wrote: >Hi, > >I wrote a small swing app to download images from an industrial camera. >I used the two way serial sample code as a starting point. The app works >fine EXCEPT for a call to jfilechooser. After I open the comm port and >then try to change the output directory or log file, the jfilechooser >winds up trying to unpark (note, parking is not something I'm really >familiar with) and doesn't. If I try to change the file or directory >before I start the comm port, it works. If I click on menu items that >don't call jfilechooser, everything is OK. If I try closing the comm >port and then try to create a jfilechooser, it locks up. There is >obviously some sort of deadlock here because the awt thread starts >waiting on something but it's not clear what. I haven't gone thru the >rxtx code yet because it's not in the file structure that netbeans wants >for debugging purposes. However, debugging code that I don't have a >clear idea of what it is supposed to do is not my idea of a good time. What is the threading structure of your code? The various high-function Swing components, such as JFileChooser, are notorious for doing Really Bad Stuff when invoked from off the Swing thread. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From bschlining at gmail.com Fri May 8 15:08:50 2009 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 8 May 2009 14:08:50 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: Bob's probably right...take look at javax.swing.SwingUtilites for the workaround to get your swing stuff invoked on the EventDispatchThread (EDT). Some swing-methods do work when called outside of the EDT, but just to be safe, do your creation and swing calls on the EDT. It's really simple, here's an example of a synchronous call. // Here's how to run stuff on the EDT from a different thread SwingUtilities.invokeAndWait(new Runnable() { public void run() { JFileChooser fc; // create, setup, show your filechooser // Get the result from the filechooser } }); To do a asynchronous call use SwingUtilities.invokeLater > >I wrote a small swing app to download images from an industrial camera. > >I used the two way serial sample code as a starting point. The app works > >fine EXCEPT for a call to jfilechooser. After I open the comm port and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090508/c21c2127/attachment-0014.html From tod at todbot.com Fri May 8 16:27:12 2009 From: tod at todbot.com (Tod E. Kurt) Date: Fri, 8 May 2009 15:27:12 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> This is the exact technique I use to let the user choose which serial port to use on startup. Here's a method I've got in many of my sketches: void choosePort() { String portlist[] = Serial.list(); String port = null; javax.swing.SwingUtilities.invokeLater(new Runnable() { public void run() { try { String port = (String) javax.swing.JOptionPane.showInputDialog( null, "Select Serial Port", "MySuperSketch", javax.swing.JOptionPane.QUESTION_MESSAGE, null, portlist, null); if( port == null ) { javax.swing.JOptionPane.showMessageDialog(null, "No port chosen, goodbye"); System.exit(1); } serialPort = port; } catch (Exception e) { e.printStackTrace(); } } } ); } On May 8, 2009, at 2:08 p, Brian Schlining wrote: > Bob's probably right...take look at javax.swing.SwingUtilites for > the workaround to get your swing stuff invoked on the > EventDispatchThread (EDT). Some swing-methods do work when called > outside of the EDT, but just to be safe, do your creation and swing > calls on the EDT. It's really simple, here's an example of a > synchronous call. > > // Here's how to run stuff on the EDT from a different thread > SwingUtilities.invokeAndWait(new Runnable() { > public void run() { > JFileChooser fc; // create, setup, show your filechooser > // Get the result from the filechooser > } > }); > > To do a asynchronous call use SwingUtilities.invokeLater > > > >I wrote a small swing app to download images from an industrial > camera. > >I used the two way serial sample code as a starting point. The app > works > >fine EXCEPT for a call to jfilechooser. After I open the comm port > and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From huangdongkai at gmail.com Sat May 9 04:46:22 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Sat, 9 May 2009 18:46:22 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Dear Trent, After I intsall the ming32-cross compile to compile the rxtxSerial.dll and testing, i found the same problem still exist. I am not sure my compiler version is the same as your's. Could you tell me the way you can success compile rxtx-2.1-7r2 release source code? Thanks for you kindly help. On Fri, May 8, 2009 at 8:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Hi Trent, >> The attach is the Make file I use to compile the rxtx. >> >> On Thu, May 7, 2009 at 10:48 AM, dongkai huang >> wrote: >> Hi Trent, >> I was followed the step on INSTALL file, did not run the >> configure, I used the Makefile.mingw32 which include on the >> source code package, and only change some path( jdk home path >> etc.). And I use the native compiler on Windows. >> The crash happened on I call the getPortIdentifiers() >> every time. >> >> On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: >> >> >> On Thu, 7 May 2009, dongkai huang wrote: >> >> Dear all, >> I recompile the rxtxSerial source code by >> MinGW32 and compile success. >> But when I run my Application which use >> rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and >> application crash. I have no >> idea why it can not work, beacuse i have not change >> any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source >> code. Did some thing I >> have missed when compile the source code on Window >> NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java >> Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at >> pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 >> mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is >> saved as: >> # >> D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please >> visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> >> Hi Dongkai >> >> Could you explain how you compiled rxtx with mingw? Did you run >> configure? Was the compiler native or a cross compiler (like >> compiling on Linux for Windows)? >> >> Is the crash happening when you first open the port or is it >> happening randomly later on? >> >> > Thanks Dongkai > > I'll look at your Makefile tomorrow. Which version of mingw was this? > > I suspect there is a problem with that makefile. I usually built that > version of rxtx for windows with a mingw32 cross compiler using the > configure script. > > The configure script may well work for you if you have a cygwin environment > with mingw instead of gcc. I'll take a look at what is different. > > -- > > Trent Jarvi > tjarvi at qbang.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090509/b729c429/attachment-0014.html From wjr at weru.ksu.edu Wed May 13 15:50:30 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Wed, 13 May 2009 16:50:30 -0500 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> Message-ID: <4A0B40A6.5070204@weru.ksu.edu> Tod's solution misses the point. He is picking and opening the serial port. That's the step before where my problem occurs. To recap: 1. I have a simple java swing app. 2. On the menu bar, there is the standard set, file, etc., of jmenu's. Under file, there is a jmenuitem, logfileopen, which pops up a jfilechooser to select a logfile and another jmenuitem, setprefix, which pops up a jdialog to allow the user to type in a file name prefix for downloaded images. 3. There is another jmenuitem that starts the commport running. 4. When logfileopen is pressed before the commport is started, it works. 5. When logfileopen is pressed after the commport is started, it hangs. 6. setprefix works whether or not the commport is started. 7. portIdentifier.open starts a thread that goes into a native method, RXTXPort.eventLoop, and never returns. 8. java.sun bugs has a bug report, 6741890, that is similar but their workaround doesn't. 9. When it locks up, there is a swing-shell thread that appears to be down in some native libraries, winshellfolder2 10. The awt-eventQ thread is unblocked but in code that says its parked. If you have anymore ideas, I'd really appreciate them. wjr Tod E. Kurt wrote: > This is the exact technique I use to let the user choose which serial > port to use on startup. Here's a method I've got in many of my sketches: > > void choosePort() { > String portlist[] = Serial.list(); > String port = null; > javax.swing.SwingUtilities.invokeLater(new Runnable() { > public void run() { > try { > String port = (String) javax.swing.JOptionPane.showInputDialog( > null, > "Select Serial Port", > "MySuperSketch", > javax.swing.JOptionPane.QUESTION_MESSAGE, > null, portlist, null); > if( port == null ) { > javax.swing.JOptionPane.showMessageDialog(null, "No port > chosen, goodbye"); > System.exit(1); > } > serialPort = port; > } > catch (Exception e) { > e.printStackTrace(); > } > } > } ); > } > > > On May 8, 2009, at 2:08 p, Brian Schlining wrote: > >> Bob's probably right...take look at javax.swing.SwingUtilites for the >> workaround to get your swing stuff invoked on the EventDispatchThread >> (EDT). Some swing-methods do work when called outside of the EDT, but >> just to be safe, do your creation and swing calls on the EDT. It's >> really simple, here's an example of a synchronous call. >> >> // Here's how to run stuff on the EDT from a different thread >> SwingUtilities.invokeAndWait(new Runnable() { >> public void run() { >> JFileChooser fc; // create, setup, show your filechooser >> // Get the result from the filechooser >> } >> }); >> >> To do a asynchronous call use SwingUtilities.invokeLater >> >> >> >I wrote a small swing app to download images from an industrial camera. >> >I used the two way serial sample code as a starting point. The app works >> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >> >then try to change the output directory or log file, the jfilechooser >> >winds up trying to unpark (note, parking is not something I'm really >> >familiar with) and doesn't. >> What is the threading structure of your code? >> >> The various high-function Swing components, such as JFileChooser, are >> notorious for doing Really Bad Stuff when invoked from off the Swing >> thread. >> >> Bob >> -- >> Bob Jacobsen, UC Berkeley >> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >> JacobsenRG >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -- >> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >> Brian Schlining >> bschlining at gmail.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx From m.j.tandy at warwick.ac.uk Wed May 13 16:42:24 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 13 May 2009 23:42:24 +0100 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A0B40A6.5070204@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> <4A0B40A6.5070204@weru.ksu.edu> Message-ID: <302aa0340905131542i601ec3f1w3b0b5879c23f8eca@mail.gmail.com> Perhaps you could post your program, or an excerpt of it sufficient to demonstrate the problem you're having, for us to have a look at? 2009/5/13 Bill Rust : > Tod's solution misses the point. He is picking and opening the serial > port. That's the step before where my problem occurs. > > To recap: > > 1. I have a simple java swing app. > 2. On the menu bar, there is the standard set, file, etc., of jmenu's. > Under file, there is a jmenuitem, logfileopen, which pops up a > jfilechooser to select a logfile and another jmenuitem, setprefix, which > pops up a jdialog to allow the user to type in a file name prefix for > downloaded images. > 3. There is another jmenuitem that starts the commport running. > 4. When logfileopen is pressed before the commport is started, it works. > 5. When logfileopen is pressed after the commport is started, it hangs. > 6. setprefix works whether or not the commport is started. > 7. portIdentifier.open starts a thread that goes into a native > method, ? ? ? ? ? ? ? ? ? ? ? ? RXTXPort.eventLoop, and never returns. > 8. java.sun bugs has a bug report, 6741890, that is similar but > their ? ? ? ? ? ? ? ? ? workaround doesn't. > 9. When it locks up, there is a swing-shell thread that appears to be > ? ? ? ?down in some native libraries, winshellfolder2 > 10. The awt-eventQ thread is unblocked but in code that says its parked. > > If you have anymore ideas, I'd really appreciate them. > > wjr > > Tod E. Kurt wrote: >> This is the exact technique I use to let the user choose which serial >> port to use on startup. ?Here's a method I've got in many of my sketches: >> >> void choosePort() { >> ? String portlist[] = Serial.list(); >> ? String port = null; >> ? javax.swing.SwingUtilities.invokeLater(new Runnable() { >> ? ? public void run() { >> ? ? ? try { >> ? ? ? ? String port = (String) javax.swing.JOptionPane.showInputDialog( >> null, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Select Serial Port", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "MySuperSketch", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? javax.swing.JOptionPane.QUESTION_MESSAGE, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? null, portlist, null); >> ? ? ? ? if( port == null ) ?{ >> ? ? ? ? ? javax.swing.JOptionPane.showMessageDialog(null, "No port >> chosen, goodbye"); >> ? ? ? ? ? System.exit(1); >> ? ? ? ? } >> ? ? ? ? serialPort = port; >> ? ? ? } >> ? ? ? catch (Exception e) { >> ? ? ? ? e.printStackTrace(); >> ? ? ? } >> ? ? } >> ? } ); >> } >> >> >> On May 8, 2009, at 2:08 p, Brian Schlining wrote: >> >>> Bob's probably right...take look at javax.swing.SwingUtilites for the >>> workaround to get your swing stuff invoked on the EventDispatchThread >>> (EDT). Some swing-methods do work when called outside of the EDT, but >>> just to be safe, do your creation and swing calls on the EDT. It's >>> really simple, here's an example of a synchronous call. >>> >>> // Here's how to run stuff on the EDT from a different thread >>> SwingUtilities.invokeAndWait(new Runnable() { >>> ? ? ? public void run() { >>> ? ? ? ? ? ?JFileChooser fc; // create, setup, show your filechooser >>> ? ? ? ? ? ?// Get the result from the filechooser >>> ? ? ? } >>> }); >>> >>> To do a asynchronous call use SwingUtilities.invokeLater >>> >>> >>> >I wrote a small swing app to download images from an industrial camera. >>> >I used the two way serial sample code as a starting point. The app works >>> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >>> >then try to change the output directory or log file, the jfilechooser >>> >winds up trying to unpark (note, parking is not something I'm really >>> >familiar with) and doesn't. >>> What is the threading structure of your code? >>> >>> The various high-function Swing components, such as JFileChooser, are >>> notorious for doing Really Bad Stuff when invoked from off the Swing >>> thread. >>> >>> Bob >>> -- >>> Bob Jacobsen, UC Berkeley >>> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >>> JacobsenRG >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >>> -- >>> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >>> Brian Schlining >>> bschlining at gmail.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From m.j.tandy at warwick.ac.uk Thu May 14 03:05:36 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 14 May 2009 10:05:36 +0100 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A0B40A6.5070204@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> <4A0B40A6.5070204@weru.ksu.edu> Message-ID: <302aa0340905140205p6ceb5a9br24e00a50e9cafa5@mail.gmail.com> Java has a built in deadlock detection utility; run your program from the command line, then (on windows) press Ctrl+Break (On Linux, Ctrl+\ does the trick I'm told). That should produce status information and a stack trace for every running thread, including locks held and locks waited on. Maybe that would contain enough information for you to work out what's locking what? 2009/5/13 Bill Rust : > Tod's solution misses the point. He is picking and opening the serial > port. That's the step before where my problem occurs. > > To recap: > > 1. I have a simple java swing app. > 2. On the menu bar, there is the standard set, file, etc., of jmenu's. > Under file, there is a jmenuitem, logfileopen, which pops up a > jfilechooser to select a logfile and another jmenuitem, setprefix, which > pops up a jdialog to allow the user to type in a file name prefix for > downloaded images. > 3. There is another jmenuitem that starts the commport running. > 4. When logfileopen is pressed before the commport is started, it works. > 5. When logfileopen is pressed after the commport is started, it hangs. > 6. setprefix works whether or not the commport is started. > 7. portIdentifier.open starts a thread that goes into a native > method, ? ? ? ? ? ? ? ? ? ? ? ? RXTXPort.eventLoop, and never returns. > 8. java.sun bugs has a bug report, 6741890, that is similar but > their ? ? ? ? ? ? ? ? ? workaround doesn't. > 9. When it locks up, there is a swing-shell thread that appears to be > ? ? ? ?down in some native libraries, winshellfolder2 > 10. The awt-eventQ thread is unblocked but in code that says its parked. > > If you have anymore ideas, I'd really appreciate them. > > wjr > > Tod E. Kurt wrote: >> This is the exact technique I use to let the user choose which serial >> port to use on startup. ?Here's a method I've got in many of my sketches: >> >> void choosePort() { >> ? String portlist[] = Serial.list(); >> ? String port = null; >> ? javax.swing.SwingUtilities.invokeLater(new Runnable() { >> ? ? public void run() { >> ? ? ? try { >> ? ? ? ? String port = (String) javax.swing.JOptionPane.showInputDialog( >> null, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Select Serial Port", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "MySuperSketch", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? javax.swing.JOptionPane.QUESTION_MESSAGE, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? null, portlist, null); >> ? ? ? ? if( port == null ) ?{ >> ? ? ? ? ? javax.swing.JOptionPane.showMessageDialog(null, "No port >> chosen, goodbye"); >> ? ? ? ? ? System.exit(1); >> ? ? ? ? } >> ? ? ? ? serialPort = port; >> ? ? ? } >> ? ? ? catch (Exception e) { >> ? ? ? ? e.printStackTrace(); >> ? ? ? } >> ? ? } >> ? } ); >> } >> >> >> On May 8, 2009, at 2:08 p, Brian Schlining wrote: >> >>> Bob's probably right...take look at javax.swing.SwingUtilites for the >>> workaround to get your swing stuff invoked on the EventDispatchThread >>> (EDT). Some swing-methods do work when called outside of the EDT, but >>> just to be safe, do your creation and swing calls on the EDT. It's >>> really simple, here's an example of a synchronous call. >>> >>> // Here's how to run stuff on the EDT from a different thread >>> SwingUtilities.invokeAndWait(new Runnable() { >>> ? ? ? public void run() { >>> ? ? ? ? ? ?JFileChooser fc; // create, setup, show your filechooser >>> ? ? ? ? ? ?// Get the result from the filechooser >>> ? ? ? } >>> }); >>> >>> To do a asynchronous call use SwingUtilities.invokeLater >>> >>> >>> >I wrote a small swing app to download images from an industrial camera. >>> >I used the two way serial sample code as a starting point. The app works >>> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >>> >then try to change the output directory or log file, the jfilechooser >>> >winds up trying to unpark (note, parking is not something I'm really >>> >familiar with) and doesn't. >>> What is the threading structure of your code? >>> >>> The various high-function Swing components, such as JFileChooser, are >>> notorious for doing Really Bad Stuff when invoked from off the Swing >>> thread. >>> >>> Bob >>> -- >>> Bob Jacobsen, UC Berkeley >>> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >>> JacobsenRG >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >>> -- >>> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >>> Brian Schlining >>> bschlining at gmail.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From cowwoc at bbs.darktech.org Fri May 15 07:18:29 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 09:18:29 -0400 Subject: [Rxtx] InputStream timeouts Message-ID: <4A0D6BA5.8020209@bbs.darktech.org> Why does InputStream.read() return -1 on timeout instead of throwing InterruptedIOException which has existed specifically for this purpose since JDK 1.0? Sockets throw SocketTimeoutException which extends InterruptedIOException. I suspect that this logic confuses BufferedInputStream as well as end-users. Can we introduce this change along with the other timeout-related changes? Gili From Steffen.DETTMER at ingenico.com Fri May 15 07:36:19 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 15 May 2009 15:36:19 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0D6BA5.8020209@bbs.darktech.org> References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <20090515133619.GC17036@elberon.bln.de.ingenico.com> * cowwoc wrote on Fri, May 15, 2009 at 09:18 -0400: > Why does InputStream.read() return -1 on timeout shouldn't it block and only avialable() should care about timeouts? That is how I understand `This method blocks until input data is available' from: http://java.sun.com/j2se/1.5.0/docs/api/java/io/InputStream.html#read() public abstract int read() throws IOException Reads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. A subclass must provide an implementation of this method. Returns: the next byte of data, or -1 if the end of the stream is reached. Throws: IOException - if an I/O error occurs. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Fri May 15 08:22:19 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 15 May 2009 17:22:19 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: >From the javadoc for InputStream: "If no byte is available because the end of the stream has been reached, the value -1 is returned." Since character timeout is not an indication of EOF condition I guess one could argue that 0 should be returned in case of timeout. On the other hand one could also argue that since no data was available (if it timed out) the serial port input stream was at the end of stream (albeit possibly temporarily only). Further the javadoc seems to forbid the return value 0 for Inputstream.read(): " This method blocks until input data is available, the end of the stream is detected, or an exception is thrown." So it can return n >= 1 , -1 or throw an exception. InputStream.read(byte[]) can return 0 but for consistency the options with the other read methods the return value for timeout needs to be -1 or an exception. It goes against my grain to think that I get an exception when I've set up a timeout and I am thus expecting a timeout to happen sometimes. So it is not an exceptional case but expected situation in which case a special return value is philosophically speaking more appropriate. So I'm against changing this behavior. I expect a lot of code depend on the -1 or at least on not getting an exception when a timeout occurs. In any case if an exception were to be thrown it should *not* be InterruptedIOException. >From the javadoc for InterruptedIOException: "An InterruptedIOException is thrown to indicate that an input or output transfer has been terminated because the thread performing it was interrupted. The field bytesTransferred indicates how many bytes were successfully transferred before the interruption occurred" I do not think this matches the case for serial port receive character timeout. I read the javadoc above so that I get this exception when the thread in my code that is performing a read or write operation gets interrupted by Thread.interrupt(). And this is used to handle exactly that case: being able to gracefully and cleanly interrupt threads. my 2 snt worth br Kusti > From: cowwoc > Date: Fri, 15 May 2009 16:18:29 +0300 > To: rxtx > Conversation: [Rxtx] InputStream timeouts > Subject: [Rxtx] InputStream timeouts > > > > Why does InputStream.read() return -1 on timeout instead of > throwing InterruptedIOException which has existed specifically for this > purpose since JDK 1.0? Sockets throw SocketTimeoutException which > extends InterruptedIOException. I suspect that this logic confuses > BufferedInputStream as well as end-users. Can we introduce this change > along with the other timeout-related changes? > > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From cowwoc at bbs.darktech.org Fri May 15 08:35:27 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 10:35:27 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <4A0D7DAF.5030705@bbs.darktech.org> I disagree with your interpretation. Read SocketTimeoutException to see what I mean. InterruptedIOException means the operation was interrupted, not necessarily by way of Thread.interrupt(). Returning 0 in case of timeout sounds wrong to me because it is a legal byte value that could have been read. Returning -1 also sounds wrong to me because this isn't strictly the end of stream. BufferedInputStream and others assume that once you reach the end of stream you will never see more data, ever. As far as I know, the core APIs are written in terms of throwing InterruptedIOException for timeouts. Gili Kustaa Nyholm wrote: > >>From the javadoc for InputStream: > > "If no byte is available because the end of the stream has been reached, the > value -1 is returned." > > > Since character timeout is not an indication of EOF condition I guess one > could argue that 0 should be returned in case of timeout. On the other hand > one could also argue that since no data was available (if it timed out) the > serial port input stream was at the end of stream (albeit possibly > temporarily only). Further the javadoc seems to forbid the return value 0 > for Inputstream.read(): > > " This method blocks until input data is available, the end of the stream is > detected, or an exception is thrown." > > So it can return n >= 1 , -1 or throw an exception. InputStream.read(byte[]) > can return 0 but for consistency the options with the other read methods the > return value for timeout needs to be -1 or an exception. > > It goes against my grain to think that I get an exception when I've set up a > timeout and I am thus expecting a timeout to happen sometimes. So it is not > an exceptional case but expected situation in which case a special return > value is philosophically speaking more appropriate. > > So I'm against changing this behavior. I expect a lot of code depend on the > -1 or at least on not getting an exception when a timeout occurs. > > In any case if an exception were to be thrown it should *not* be > InterruptedIOException. > >>From the javadoc for InterruptedIOException: > > > "An InterruptedIOException is thrown to indicate that an input or output > transfer has been terminated because the thread performing it was > interrupted. The field bytesTransferred indicates how many bytes were > successfully transferred before the interruption occurred" > > I do not think this matches the case for serial port receive character > timeout. I read the javadoc above so that I get this exception when the > thread in my code that is performing a read or write operation gets > interrupted by Thread.interrupt(). And this is used to handle exactly that > case: being able to gracefully and cleanly interrupt threads. > > > > my 2 snt worth br Kusti > > > > >> From: cowwoc >> Date: Fri, 15 May 2009 16:18:29 +0300 >> To: rxtx >> Conversation: [Rxtx] InputStream timeouts >> Subject: [Rxtx] InputStream timeouts >> >> >> >> Why does InputStream.read() return -1 on timeout instead of >> throwing InterruptedIOException which has existed specifically for this >> purpose since JDK 1.0? Sockets throw SocketTimeoutException which >> extends InterruptedIOException. I suspect that this logic confuses >> BufferedInputStream as well as end-users. Can we introduce this change >> along with the other timeout-related changes? >> >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From m.j.tandy at warwick.ac.uk Fri May 15 09:17:36 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Fri, 15 May 2009 16:17:36 +0100 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <302aa0340905150817o39812d7y1b896004a2dcc2ab@mail.gmail.com> > I disagree with your interpretation. Read SocketTimeoutException to see > what I mean. InterruptedIOException means the operation was interrupted, > not necessarily by way of Thread.interrupt(). Strangely enough, the javadoc for InterruptedIOException says: "An InterruptedIOException is thrown to indicate that an input or output transfer has been terminated because the thread performing it was interrupted."[1] But the subclass SocketTimeoutException is used differently - here's an example from sun.net.httpserver.request: /** * block() only called when available==0 and buf is empty */ private synchronized void block () throws IOException { long currtime = server.getTime(); long maxtime = currtime + readTimeout; while (currtime < maxtime) { if (selector.select (readTimeout) == 1) { selector.selectedKeys().clear(); available (); return; } currtime = server.getTime(); } throw new SocketTimeoutException ("no data received"); } So it seems that SocketTimeoutExceptions get thrown not upon thread interruptions, but a certain time after a blocking read is started. [1] http://java.sun.com/javase/6/docs/api/java/io/InterruptedIOException.html From cowwoc at bbs.darktech.org Fri May 15 11:06:53 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 13:06:53 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0DA0F4.9050203@bbs.darktech.org> References: <4A0DA0F4.9050203@bbs.darktech.org> Message-ID: <4A0DA12D.2050303@bbs.darktech.org> Forgot to CC the list. Gili cowwoc wrote: > > "Thread was interrupted" does not necessarily mean > Thread.interrupt(). It just means that the operation (run by the thread) > was interrupted. If you read the beginning sentence for > InterruptedIOException it reads "Signals that an I/O operation has been > interrupted". This says nothing about the thread itself. Michael's > subsequent post about SocketTimeoutException reinforces that point. > > By the way, I think that in general you need to interpret the > Javadoc for core classes in a broader sense than it seems. Older Javadoc > (from version 1.0) used to mention implementation details that were not > necessarily important and limited the applicability of the classes. > Newer documentation tends to go out of its way to avoid mentioning such > implementation detail and I believe that's a good thing. When > InterruptedIOException was written, Thread.interrupt() was probably the > only way to interrupt I/O operations. Nowadays there are others. Sun has > generalized its meaning over time as evident by SocketTimeoutException. > At least, that's my interpretation :) > > Gili > > Kustaa Nyholm wrote: >>> I disagree with your interpretation. Read >>> SocketTimeoutException to >>> see >>> what I mean. InterruptedIOException means the operation was interrupted, >>> not necessarily by way of Thread.interrupt(). >> >> Well SocketTimeoutException javadoc only says, very briefly: >> >> "Signals that a timeout has occurred on a socket read or accept." >> >> So that is not too helpful. But since it is derived from >> InterruptedIOException my interpretation it that they have an 'is-a' >> relationship and InterruptedIOException needs to honor the contract of >> InterruptedIOException which says: >> >> "...because the thread performing it was interrupted." >> >> To me this very specifically talks about interrupting threads with >> Thread.interrupt() >> >> >>> Returning 0 in case of timeout sounds wrong to me because it >>> is a >>> legal >>> byte value that could have been read. >> Agreed, that's what I tried to say. 0 is a legal byte value for read() to >> return so that cannot be used. For read read(byte[]) which returns the >> number of bytes read 0 could be used but there again 0 can be returned >> if 0 >> byte[] size is 0. So there again 0 is not a good option. >> >>> Returning -1 also sounds wrong to >>> me because this isn't strictly the end of stream. >> Like I said, it isn't strictly the end of stream. But also does not >> forbid treating it as (temporary) end of stream. >> >>> BufferedInputStream >>> and others assume that once you reach the end of stream you will never >>> see more data, ever. >> Can you provide a reference for that. >> >>> As far as I know, the core APIs are written in >>> terms of throwing InterruptedIOException for timeouts. >> Would also like to see something to support that. >> >> >> The behavior of throwing an exception on timeout is also a little bit >> problematic, consider: >> >> byte buf[1000]; >> int n=ins.read(buf); >> // do something with the n bytes received >> >> What happens if a timeout occurs before we have received 1000 bytes? >> >> If an exception is thrown then the user of the read() needs to handle >> the bytes received in two places or else those last <1000 bytes are lost. >> A better solution would be to return the bytes received so far and throw >> the exception on the next call (if any). But the main point is that >> neither of these case obviously correct and neither is specified in the >> javadocs. Where as a lot of code that just handles the return value >> of read(byte[]) correctly works without any further ado. >> >> >> >> The main thing is that I think we should not break existing applications, >> which I expect are not handling InterruptedIOException but many of >> which may >> depend on getting back -1 in case of timeouts. >> >> It has been a while since I used the javax.javacomm but I seem to recall >> that it returned -1 and I think this is the defining standard. >> >> I expect most rxtx users are more interested in compatibility and >> stability >> than semantic niceties and improving the API. >> >> br Kusti >> >> >> > From johnny.luong at trustcommerce.com Fri May 15 13:16:15 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Fri, 15 May 2009 12:16:15 -0700 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0DA12D.2050303@bbs.darktech.org> References: <4A0DA0F4.9050203@bbs.darktech.org> <4A0DA12D.2050303@bbs.darktech.org> Message-ID: <4A0DBF7F.50808@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 cowwoc wrote: | Forgot to CC the list. | | Gili | | cowwoc wrote: |> "Thread was interrupted" does not necessarily mean |> Thread.interrupt(). It just means that the operation (run by the thread) |> was interrupted. If you read the beginning sentence for |> InterruptedIOException it reads "Signals that an I/O operation has been |> interrupted". This says nothing about the thread itself. Michael's |> subsequent post about SocketTimeoutException reinforces that point. |> |> By the way, I think that in general you need to interpret the |> Javadoc for core classes in a broader sense than it seems. Older Javadoc |> (from version 1.0) used to mention implementation details that were not |> necessarily important and limited the applicability of the classes. |> Newer documentation tends to go out of its way to avoid mentioning such |> implementation detail and I believe that's a good thing. When |> InterruptedIOException was written, Thread.interrupt() was probably the |> only way to interrupt I/O operations. Nowadays there are others. Sun has |> generalized its meaning over time as evident by SocketTimeoutException. |> At least, that's my interpretation :) |> |> Gili |> |> Kustaa Nyholm wrote: |>>> I disagree with your interpretation. Read |>>> SocketTimeoutException to |>>> see |>>> what I mean. InterruptedIOException means the operation was interrupted, |>>> not necessarily by way of Thread.interrupt(). |>> Well SocketTimeoutException javadoc only says, very briefly: |>> |>> "Signals that a timeout has occurred on a socket read or accept." |>> |>> So that is not too helpful. But since it is derived from |>> InterruptedIOException my interpretation it that they have an 'is-a' |>> relationship and InterruptedIOException needs to honor the contract of |>> InterruptedIOException which says: |>> |>> "...because the thread performing it was interrupted." |>> |>> To me this very specifically talks about interrupting threads with |>> Thread.interrupt() |>> |>> |>>> Returning 0 in case of timeout sounds wrong to me because it |>>> is a |>>> legal |>>> byte value that could have been read. |>> Agreed, that's what I tried to say. 0 is a legal byte value for read() to |>> return so that cannot be used. For read read(byte[]) which returns the |>> number of bytes read 0 could be used but there again 0 can be returned |>> if 0 |>> byte[] size is 0. So there again 0 is not a good option. |>> |>>> Returning -1 also sounds wrong to |>>> me because this isn't strictly the end of stream. |>> Like I said, it isn't strictly the end of stream. But also does not |>> forbid treating it as (temporary) end of stream. |>> |>>> BufferedInputStream |>>> and others assume that once you reach the end of stream you will never |>>> see more data, ever. |>> Can you provide a reference for that. |>> |>>> As far as I know, the core APIs are written in |>>> terms of throwing InterruptedIOException for timeouts. |>> Would also like to see something to support that. |>> |>> |>> The behavior of throwing an exception on timeout is also a little bit |>> problematic, consider: |>> |>> byte buf[1000]; |>> int n=ins.read(buf); |>> // do something with the n bytes received |>> |>> What happens if a timeout occurs before we have received 1000 bytes? |>> |>> If an exception is thrown then the user of the read() needs to handle |>> the bytes received in two places or else those last <1000 bytes are lost. |>> A better solution would be to return the bytes received so far and throw |>> the exception on the next call (if any). But the main point is that |>> neither of these case obviously correct and neither is specified in the |>> javadocs. Where as a lot of code that just handles the return value |>> of read(byte[]) correctly works without any further ado. |>> |>> |>> |>> The main thing is that I think we should not break existing applications, |>> which I expect are not handling InterruptedIOException but many of |>> which may |>> depend on getting back -1 in case of timeouts. |>> |>> It has been a while since I used the javax.javacomm but I seem to recall |>> that it returned -1 and I think this is the defining standard. |>> |>> I expect most rxtx users are more interested in compatibility and |>> stability |>> than semantic niceties and improving the API. |>> |>> br Kusti |>> |>> |>> | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi, Maybe a better approach (improving the API) would be to consider implementing a NIO interface atop the underlying serial communication... ~ if someone desires the existing behavior, then they use a facade that lies atop of the NIO and provide the same quirks associated with it. As I see it, the implementation overrides the general contract of the InputStream to provide for the timeout functionality and it would be somewhat troublesome to expect a user of that API to catch subclasses of IOException. Best, Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoNv38ACgkQnQTBLXttTeWZ+wCeO4CTrI5l+vLPrjHl8fBj7FOL Ft8AnjQ7bXnvMhOlwZdK5CYAuoQeQ9u0 =QAax -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon May 18 03:49:50 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 11:49:50 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <20090518094950.GG17036@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, May 15, 2009 at 17:22 +0300: > >From the javadoc for InputStream: > > Since character timeout is not an indication of EOF condition I > guess one could argue that 0 should be returned in case of > timeout. A blocking operation logically has no timeout. It is blocking. Forever, until EOF or an error. This IMHO renders usage of read() useless and read(byte[]) must be used (or no InputStream). > On the other hand one could also argue that since no data was > available (if it timed out) IMHO, read() must not time out. What would happen with a small simple console app that is relying that InputStream is implemented as required by specification? It cannot tell `no byte was received but this is not an error, please call me again' - and why should it? I think, if this is not suited, i.e. if the application may want a byte but also may not want a byte, no blocking function must be invoked, but a select must be called instead or, if no select-style function is avialable, polling must be used. This is the InputStream way (block or poll). For streams the `may or may not want a byte' may sound unlikely, but in practice this is what happens, for instance, if there is some CANCEL button in a GUI or so. Closing the stream often also is no option because it cannot be reopend but it might be needed again later. In classic unix apps often signals were used (read(2) can return EINTR), but in Java this isn't possible AFAIK. EINTR IMHO has not much relation to InterruptedIOException and I think InterruptedIOException cannot be `enforced' without doing harm. > It goes against my grain to think that I get an exception when > I've set up a timeout yeah, I thought the same and when I hit this InputStream the first time I though: ohh, a bug. Or a bunch of :-) As specified, InputStream has no timeout. If you set a timeout, then somewhere else (e.g. a sub class). In this case, the sub class should also offer a way to wait for this timeout (e.g. a select style function). In practice, this makes not much sense, leaving the options not to use it at all (but what else then?) or to violate the specification. Unfortunately it seems that subclasses add setTimeout but no select() or tryRead() or simply a available()-style with a timeout parameter. Then applications would simply use this subclasses. In practice, then it does not help that they derive InputStream at all, so personally I think they should not derive from it but instead define something with a meaning :-) But I think in practice, for read(byte[]) returning 0 (e.g. in case of [intercharacter] timeout) for many people seems straightforward - so this is probably what most people will expect. (an interesting question is how those bugs happend to the Java guys, because those topics are well known since ages and solved, for instance, in the BSD socket API, but probably they didn't know it. It took years but now it seems they understood and tried it again by some NIO which is more in the `usual way'. Next version might be usable - I wouldn't be surprised if this one then is BSD socket API alike :-) SCNR). So in practice I think: - don't use read() but read(byte[]) or read(byte[], int, int) - handle `0 bytes read' situation - polling avialable() in practice may often not be suited because avialable() has no timeout parameter and if response time is important, small polling intervals would be needed which generate load - try to avoid using InputStream (from applications) directly because it sucks and it is /not/ generic (implementations may interpret it differently because it MUST be interpreted because the specification makes not much sense in many cases) - IOException and InterruptedIOException are for I/O error situations. Additionally I think, InterruptedIOException.bytesTransferred cannot be reliable because there are cases where the OS cannot surely know this and thus cannot tell it the JVM also, peer may have not received them even if they were sent As far as I know this is exactly what rxtx is doing. When having many clients this require many threads and might be less performant, so best is not to have one thousand serial ports :-) Returning 0 here IMHO also is the only option that does not `directly' violate the spec. It tells `there is an attempt to read at least one byte.' so someone could argue that the dear computer `attempted but found no time to do so' :-) > So I'm against changing this behavior. I expect a lot of code > depend on the -1 or at least on not getting an exception when a > timeout occurs. Yes, I agree, -1 means End of file (or closed by peer) and exceptions are for errors. If exceptions should be added I think it could be made configurable. For instance by some Rs232InputStream.enableException(IOException e), store this exception and later if (e != null) throw e.clone() or so. > I do not think this matches the case for serial port receive character > timeout. I read the javadoc above so that I get this exception when the > thread in my code that is performing a read or write operation gets > interrupted by Thread.interrupt(). And this is used to handle exactly that > case: being able to gracefully and cleanly interrupt threads. (well, I think Thread.interrupt() also is a big topic on its own and I'm afraid there is no really reliable mechanism for `cleanly interrupt threads' and maybe even that logically threads cannot be interrupted cleanly at all) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From rxtx at qbang.org Mon May 18 05:17:08 2009 From: rxtx at qbang.org (VIAGRA ® Official Site) Date: Mon, 18 May 2009 05:17:08 -0600 Subject: [Rxtx] DISCOUNT ID42992 75% 0FF on Pfizer ! Message-ID: <200905181117.n4IBH8ku024296@rxtx.qbang.org> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/4c172d08/attachment-0005.html From Kustaa.Nyholm at planmeca.com Mon May 18 07:20:40 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 18 May 2009 16:20:40 +0300 Subject: [Rxtx] InputStream timeouts Message-ID: Oops, sorry sent this to Steffen directly instead of mailing list. So here for the list: > A blocking operation logically has no timeout. It is blocking. > Forever, until EOF or an error. This IMHO renders usage of read() > useless and read(byte[]) must be used (or no InputStream). This is true, however read(byte[]) too is blocking so logically that (allowing it to return with value 0 in case of timeout) is no better (or worse) than read(). According to InputsStream javadoc only when byte[].length is 0 is read(byte[]) non blocking and can return 0. But to be clear: I'm in favor of returning 0 in case of timeouts for read(byte[]) and -1 for read(). > >> On the other hand one could also argue that since no data was >> available (if it timed out) > > IMHO, read() must not time out. IMHO read() should behave consistently with respect to the other read(...) methods. If we allow them to timeout, we should also allow read() to timeout. And in that case we need a return value that separates that case from normal return value (0-255), so -1 seems like a good candidate. > What would happen with a small > simple console app that is relying that InputStream is > implemented as required by specification? It cannot tell `no byte > was received but this is not an error, please call me again' > - and why should it? I think that the simple console app would be just fine, because timeouts are disabled by default so the simple applications are not affected. > > In practice, this makes not much sense, leaving the options not > to use it at all (but what else then?) or to violate the > specification. The javadoc for CommPort.getInputStream() spells out the rules for timeouts: http://java.sun.com/products/javacomm/reference/api/javax/comm/CommPort.html #getInputStream() So, IMO, while it is interesting to discuss these things the javacomm specs is quite clear about blocking behavior and although there is some conflict between how (file) inputstream behaves and Commport inputstreams behave, I think rxtx should adhere to the javacomm spec. > But I think in practice, for read(byte[]) returning 0 (e.g. in > case of [intercharacter] timeout) for many people > seems straightforward - so this is probably what most people will > expect. Agreed, I'm 100% sure there are lots of people out there that use timeouts and depend on the current behavior. Changing this would not help them but infuriate them. > > (well, I think Thread.interrupt() also is a big topic on its own > and I'm afraid there is no really reliable mechanism for > `cleanly interrupt threads' and maybe even that logically > threads cannot be interrupted cleanly at all) Would be interesting to discuss that too but that is beyond the topic of this thread. However I still believe that the InterruptedIOException was introduced so that blocking IO calls could gracefully 'return' if the calling thread was interrupted. Weather this is reliable or clean or graceful could be discussed but to me it seem reasonable. If you have a thread that is blocking on some I/O we need a mechanism that allows stopping that thread in a controlled manner and InterruptedIOException seems to provide this. cheers Kusti From Steffen.DETTMER at ingenico.com Mon May 18 09:18:37 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 17:18:37 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <20090518151837.GS17036@elberon.bln.de.ingenico.com> [OT] * Kustaa Nyholm wrote on Mon, May 18, 2009 at 16:20 +0300: > > A blocking operation logically has no timeout. It is blocking. > > Forever, until EOF or an error. This IMHO renders usage of read() > > useless and read(byte[]) must be used (or no InputStream). > This is true, however read(byte[]) too is blocking so logically that > (allowing it to return with value 0 in case of timeout) is no better > (or worse) than read(). According to InputsStream javadoc only when > byte[].length is 0 is read(byte[]) non blocking and can return 0. I think the essential difference is that for read(byte[]) returning 0 is somewhat clear, but for read() 0 is a valid byte and thus it would be a horrible mess to also use it for timeouts :) > >> On the other hand one could also argue that since no data was > >> available (if it timed out) > > > > IMHO, read() must not time out. > > IMHO read() should behave consistently with respect to the > other read(...) methods. If we allow them to timeout, we should > also allow read() to timeout. And in that case we need a return > value that separates that case from normal return value (0-255), > so -1 seems like a good candidate. Well, but then this is not consistently to EOF handling... (and if read() cannot be consistent, maybe not using it at all is an option?) > > What would happen with a small simple console app that is > > relying that InputStream is implemented as required by > > specification? It cannot tell `no byte was received but this > > is not an error, please call me again' - and why should it? > I think that the simple console app would be just fine, because > timeouts are disabled by default so the simple applications are > not affected. Not setting timeouts IMHO does not mean no timeouts will be applied but that some default timeout is used instead, which could be infinite or some OS value, which in turn may be configurable (like the TCP wait timeouts). > > In practice, this makes not much sense, leaving the options not > > to use it at all (but what else then?) or to violate the > > specification. > > The javadoc for CommPort.getInputStream() spells out the rules for > timeouts: > > http://java.sun.com/products/javacomm/reference/api/javax/comm/CommPort.html > #getInputStream() > So, IMO, while it is interesting to discuss these things > the javacomm specs is quite clear about blocking behavior > and although there is some conflict between how (file) inputstream > behaves and Commport inputstreams behave, I think rxtx should > adhere to the javacomm spec. I think first this does not clearly state what happens a read caller when a timeout occures and second IMHO it does violate the InputStream specification contract (API/javadoc). Formally speaking, it is a bug :-) Also those `advisory methods' in a formal interface are bad, I think. But another topic and discussed already several times :) Yes, in the end it seems the clear correct possiblity (no timeouts) makes no sense, so something pragmatic is needed :-) > > But I think in practice, for read(byte[]) returning 0 (e.g. in > > case of [intercharacter] timeout) for many people > > seems straightforward - so this is probably what most people will > > expect. > Agreed, I'm 100% sure there are lots of people out there that > use timeouts and depend on the current behavior. Changing this > would not help them but infuriate them. yeah, and when shifting to another type of InputStream suddenly they may break, rendering that interface a bit useless, but this is all we have... Correct IMHO would be that the compiler is able to check whether an interface supports timeouts or not (i.e. all methods exist and work as specified or a different interface must be used. Lets say we would have InputStream and InputStreamTimeout or whatever, there would be so many possibilities, but most with own disadvantages). Well, I wonder why they did not even add a timeout parameter to available() and why they forgot about write timeouts completely (also there is no counterpart to available()). Anyway. > > (well, I think Thread.interrupt() also is a big topic on its own > > and I'm afraid there is no really reliable mechanism for > > `cleanly interrupt threads' and maybe even that logically > > threads cannot be interrupted cleanly at all) > Would be interesting to discuss that too but that is beyond the > topic of this thread. However I still believe that the > InterruptedIOException was introduced so that blocking > IO calls could gracefully 'return' if the calling thread > was interrupted. Yes, maybe they forgot it in first place, then found that read can throw IOExceptions only and thus invented InterruptedIOException for InterruptedException-alike cases? but anyway. > Weather this is reliable or clean or graceful could be > discussed but to me it seem reasonable. (With not reliable I mean, when for instance you wanted to write 10 byte and you get this exception telling 5 byte have been written, you cannot be sure what this means. Maybe the 6th byte is in a fifo or whatever. I think best is to avoid the need to handle this). > If you have a thread that is blocking on some I/O we need a > mechanism that allows stopping that thread in a controlled > manner and InterruptedIOException seems to provide this. I think also this is not reliable, because even if the JVM knows a thread is supposed to be `killed', I see at least two issues: first is that native code may be active and cannot be forced to return and second it could be that the thread would need to perform clean up tasks, and since Java does not support RAII (destructors cannot clean), at least you get in trouble when exceptions happening during this cleanup (i.e. exceptions after the thread stops). This in turn IMHO is likely to happen because a well-known situation to interrupt such a thread might be after some error, and after errors exceptions I think happen more often (because less well tested and others). Let's say the thread uses an InputStream (owned by someone else) and now discards it by calling it's close (which should be a delete - because what is an input stream which is closed? Obviously it is not an input stream anymore :-)). Now you might have a special InputStream requiring special things (it might be a protocol requiring some final quit message to be sent, it might need not to close it if used by someone else, too, additional actions may be needed). Logically this could be implemented (turing complete language :-)), but in practice it might not be possible, simply because too complex (to do it right in all circumstances). oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Mon May 18 10:02:39 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 18 May 2009 19:02:39 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: > Not setting timeouts IMHO does not mean no timeouts will be > applied but that some default timeout is used instead, which > could be infinite or some OS value, which in turn may be > configurable (like the TCP wait timeouts). > The javadoc says: "By default, receive timeout is not enabled." and "By default, receive threshold is not enabled." thus (from getInputStream javadoc): "block until any data is available" which is consistent InputStream contract. > I think first this does not clearly state what happens a read > caller when a timeout occures That is true. > and second IMHO it does violate the > InputStream specification contract (API/javadoc). Formally > speaking, it is a bug :-) Agreed, but I think given the advantages you get by using InputStream (as means of reading the serial port as opposed to coming up with some totally new Stream concept) I think this was reasonable compromise and bending of the rules. > yeah, and when shifting to another type of InputStream suddenly > they may break, rendering that interface a bit useless, but this > is all we have... Exactly. > (With not reliable I mean, when for instance you wanted to write > 10 byte and you get this exception telling 5 byte have been > written, you cannot be sure what this means. Maybe the 6th byte > is in a fifo or whatever. I think best is to avoid the need to > handle this). I think all we can assume is that at least 5 bytes have been written into the native driver, weather they are in the fifo or whatever we cannot know. But as you wrote, best avoid depending on this behaviour. > I think also this is not reliable, because even if the JVM knows > a thread is supposed to be `killed', I see at least two issues: > first is that native code may be active and cannot be forced to > return Yes, but this is sort of implementation detail, not an API or Java design issue. The JVM and system class implementations should guarantee this (I bet they don't, consistently, for all platforms and OSes). > and second it could be that the thread would need to > perform clean up tasks, and since Java does not support RAII > (destructors cannot clean), at least you get in trouble when > exceptions happening during this cleanup (i.e. exceptions after > the thread stops). I sort of see what you mean, but still I do not see how this could happen if the cleanup catches exceptions properly. But then I've not studied this in detail. > This in turn IMHO is likely to happen because > a well-known situation to interrupt such a thread might be after > some error, and after errors exceptions I think happen more often > (because less well tested and others). > > Let's say the thread uses an InputStream (owned by someone else) > and now discards it by calling it's close (which should be a > delete - because what is an input stream which is closed? > Obviously it is not an input stream anymore :-)). > Now you might have a special InputStream requiring special things > (it might be a protocol requiring some final quit message to be > sent, it might need not to close it if used by someone else, > too, additional actions may be needed). > Logically this could be implemented (turing complete language :-)), > but in practice it might not be possible, simply because too > complex (to do it right in all circumstances). Ok, I think I understand what you mean: you are saying that what mention aboce "if the cleanup catches exceptions properly" maybe be and often is too difficult/complex to implement and test properly? Yeah, seen that, been there, fallen for it... cheers Kusti From Steffen.DETTMER at ingenico.com Mon May 18 10:39:26 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 18:39:26 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: <20090518163925.GV17036@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Mon, May 18, 2009 at 19:02 +0300: > > Not setting timeouts IMHO does not mean no timeouts will be > > applied but that some default timeout is used instead, which > > could be infinite or some OS value, which in turn may be > > configurable (like the TCP wait timeouts). > > > The javadoc says: > "By default, receive timeout is not enabled." > and > "By default, receive threshold is not enabled." mmm... but they are optional, so what if a driver does not support timeouts but underlaying comm interface does? anyway, *I* would not rely (but loop) but maybe this is not needed. > > and second IMHO it does violate the > > InputStream specification contract (API/javadoc). Formally > > speaking, it is a bug :-) > Agreed, but I think given the advantages you get by using > InputStream (as means of reading the serial port as opposed > to coming up with some totally new Stream concept) I think > this was reasonable compromise and bending of the rules. I don't like InputStream at all. I think it is not an abstraction to remove and later re-add (hack in) needing things. I dislike that noone knows whether it streams bytes or chars or unicode or whatever. Also, I'm used birectional things (`all things are files') for communications, I think it is simpler. So InputStream IMHO is oversimplified. Maybe it was inspired by unix line discipline (but you can select it :-)). Who knows. Anyway. > > I think also this is not reliable, because even if the JVM knows > > a thread is supposed to be `killed', I see at least two issues: > > first is that native code may be active and cannot be forced to > > return > Yes, but this is sort of implementation detail, not an API or > Java design issue. The JVM and system class implementations should > guarantee this (I bet they don't, consistently, for all platforms > and OSes). I think when no reasonable implementation is possible, probably the design is not good. If there is no reasonable way to shutdown (kill) a thread (which is the case IMHO), it makes not much sense to design it. Instead, some mechanism would be needed. I guess the InterruptedException in fact is such a kind of mechanism. I'm not sure but I think Java itself disencourages to use it. > > and second it could be that the thread would need to > > perform clean up tasks, and since Java does not support RAII > > (destructors cannot clean), at least you get in trouble when > > exceptions happening during this cleanup (i.e. exceptions after > > the thread stops). > I sort of see what you mean, but still I do not see how this > could happen if the cleanup catches exceptions properly. But > then I've not studied this in detail. > Ok, I think I understand what you mean: you are saying that > what mention aboce "if the cleanup catches exceptions properly" > maybe be and often is too difficult/complex to implement and > test properly? Yes, since it should work for any implementation, it should work for InputStreams that call abitrary complex read operations. I have applications where the read leads to some CORBA calls to a remote C++ application which also has its complexity. Now in some finally {} exceptions can occure, for instance during member destruction (closing). For example, if you have a facade like implementation with: { old = setMyLogLevel(off); for (i=0; i Yeah, seen that, been there, fallen for it... (welcome in the club :-)) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bill7007 at gmail.com Mon May 18 11:08:45 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 18 May 2009 13:08:45 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090518151837.GS17036@elberon.bln.de.ingenico.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: I can add this thought, I think the timeout is part of a protocol, which should sit above RXTX. The main feature needed in RXTX to support a protocol using timeouts is a way to interrupt it into a known state, like a reset() function. The function should cause an exception to any associated thread that was waiting on IO, maybe a unique exception due to reset() call. An IO (as opposed to Interrupted) exception may be better since the reset() has to leave a known state which may affect IO in progress. I helped work a similar situation in a CAN bus protocol. In the protocol, a send would be followed by a wait for receive. A timeout thread was enabled which caused an "alarm" event to any registered handlers upon timeout. A receive canceled the timeout alarm. The timing and thread coordination is tricky but that is all left to the protocol code. The protocols timeout event handler reset the CAN controller to get it into a known state for a retry. The reset caused an IO exception to the waiting read thread which could check that a timeout had caused it. So, if timeout is considered part of a higher level protocol class, read and write don't need special interface features as long as there is a way for a waiting state in native code to be forced to exit in a reliable, detectable, manner. +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/c9b25045/attachment-0004.html From johnny.luong at trustcommerce.com Mon May 18 11:49:53 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 18 May 2009 10:49:53 -0700 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: <4A119FC1.3090700@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Johnson wrote: | I can add this thought, I think the timeout is part of a protocol, which | should sit above RXTX. The main feature needed in RXTX to support a protocol | using timeouts is a way to interrupt it into a known state, like a reset() | function. The function should cause an exception to any associated thread | that was waiting on IO, maybe a unique exception due to reset() call. An IO | (as opposed to Interrupted) exception may be better since the reset() has to | leave a known state which may affect IO in progress. | | I helped work a similar situation in a CAN bus protocol. In the protocol, a | send would be followed by a wait for receive. A timeout thread was enabled | which caused an "alarm" event to any registered handlers upon timeout. A | receive canceled the timeout alarm. The timing and thread coordination is | tricky but that is all left to the protocol code. The protocols timeout | event handler reset the CAN controller to get it into a known state for a | retry. The reset caused an IO exception to the waiting read thread which | could check that a timeout had caused it. | | So, if timeout is considered part of a higher level protocol class, read and | write don't need special interface features as long as there is a way for a | waiting state in native code to be forced to exit in a reliable, detectable, | manner. | | +BillJ | | | | ------------------------------------------------------------------------ | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx Hi Bill, This is all conjecture and probably a lot of work in practice, so its just a train of thought at this point (via NIO)... Supposer SerialPort were to implement a method that returned "SerialPortChannel" which worked along similar lines as a SocketChannel. ~ Then you could in practice, have a Selector object that did the timeout you described above (via a register method)... your read and write methods could block or not block and it would be a lot easier to drive multiple serial ports than what you have today. - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoRn8EACgkQnQTBLXttTeXm0gCfaua0ej3Rt0fogRR68bbEFG0Z BTwAn1s79U8ZU0yj6xcND8gyHzDmKKqq =ThWj -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon May 18 11:54:10 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 19:54:10 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: <20090518175409.GW17036@elberon.bln.de.ingenico.com> (OT) * Bill Johnson wrote on Mon, May 18, 2009 at 13:08 -0400: > I can add this thought, I think the timeout is part of a > protocol, which should sit above RXTX. Probably actually on both levels timeouts can be helpful; if there is some PPP/TCP or other full duplex multiplexing protcol I think at least it is nice to be able to read with some reasonable timeout(s). > I helped work a similar situation in a CAN bus protocol. In the > protocol, a send would be followed by a wait for receive. A > timeout thread was enabled which caused an "alarm" event to > any registered handlers upon timeout. A receive canceled the > timeout alarm. The timing and thread coordination is tricky but > that is all left to the protocol code. (this Bosch car protocol?) But if the protocol implementation knows the timeout value, wouldn't it be easier and suited better to have some way to apply it to the reads without needing multithreading? Was the implementation in Java? How to cancel the receive by the timeout alarm? Was it (protocol thread implementation) internally polling? You said later, `a way for a waiting state in native code to be forced to exit in a reliable, detectable, manner'. Sounds complicated :) Is this a generic requirement? I think, protocols often can be implemented to use InputStream (or some other interface) but also to offer the same interface (like the decorator pattern). At least when `stacking' such protocols it can become quite difficult, even if having an own thread per protocol instance. Of course heavily depends on the project and situation. Well, interesting topic :) > The protocols timeout event handler reset the CAN controller to > get it into a known state for a retry. The reset caused an IO > exception to the waiting read thread which could check that a > timeout had caused it. Ohh, the CAN controller must be reset? Though they would handle a whole frame automatically. I have no clue about this; surely it is very specific and complex. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bill7007 at gmail.com Mon May 18 12:25:19 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 18 May 2009 14:25:19 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A119FC1.3090700@trustcommerce.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <4A119FC1.3090700@trustcommerce.com> Message-ID: Hi Johnny, I think a SerialPortChannel could be a good example. It uses an underlying Socket which uses an underlying implementation to support open, timeouts, etc. As part of the implementation is where the current RXTX could come in, provided there is a way to back out of a blocking situation. +BillJ On Mon, May 18, 2009 at 1:49 PM, Johnny Luong < johnny.luong at trustcommerce.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Bill Johnson wrote: > | I can add this thought, I think the timeout is part of a protocol, which > | should sit above RXTX. > ... > > Hi Bill, > > This is all conjecture and probably a lot of work in practice, so its > just a train of thought at this point (via NIO)... > > Supposer SerialPort were to implement a method that returned > "SerialPortChannel" which worked along similar lines as a SocketChannel. > ~ Then you could in practice, have a Selector object that did the timeout > you described above (via a register method)... your read and write > methods could block or not block and it would be a lot easier to drive > multiple serial ports than what you have today. > > - -Johnny > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkoRn8EACgkQnQTBLXttTeXm0gCfaua0ej3Rt0fogRR68bbEFG0Z > BTwAn1s79U8ZU0yj6xcND8gyHzDmKKqq > =ThWj > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/0a44a920/attachment-0004.html From lyon at docjava.com Mon May 18 13:18:53 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 18 May 2009 15:18:53 -0400 Subject: [Rxtx] image capture In-Reply-To: References: Message-ID: Hi All, I know this is off-topic, but we have so many native method interface experts here, I just had to ask; Is anyone able to do image capture on a 64 bit mac, using Java? QT4J is not loadable using Java 6 (AFAIK). Thanks! - Doug From bill7007 at gmail.com Mon May 18 13:24:04 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 18 May 2009 15:24:04 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090518175409.GW17036@elberon.bln.de.ingenico.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> Message-ID: On Mon, May 18, 2009 at 1:54 PM, Steffen DETTMER < Steffen.DETTMER at ingenico.com> wrote: > (OT) > > * Bill Johnson wrote on Mon, May 18, 2009 at 13:08 -0400: > > I can add this thought, I think the timeout is part of a > > protocol, which should sit above RXTX. > > Probably actually on both levels timeouts can be helpful; if > there is some PPP/TCP or other full duplex multiplexing protcol I > think at least it is nice to be able to read with some reasonable > timeout(s). I think timeout at the native level does not fit well with a read() concept of timeout because it depends on the protocol not really on the read(). > > > I helped work a similar situation in a CAN bus protocol. In the > > protocol, a send would be followed by a wait for receive. A > > timeout thread was enabled which caused an "alarm" event to > > any registered handlers upon timeout. A receive canceled the > > timeout alarm. The timing and thread coordination is tricky but > > that is all left to the protocol code. > > (this Bosch car protocol?) > > But if the protocol implementation knows the timeout value, > wouldn't it be easier and suited better to have some way to apply > it to the reads without needing multithreading? > If you are waiting on a read and you are waiting on a timeout at the same time, that is two logical threads. Maybe you are looping check for one of two condition, character or timeout, but I think its the same logically as waiting for a character or a timeout exception. It is a special case where you try to read except if it take too long, sound a little like code? > Was the implementation in Java? How to cancel the receive by the > timeout alarm? Was it (protocol thread implementation) internally > polling? > The CAN bus was Java on a TINI embedded system for a warehouse system. It implemented a guaranteed delivery data path patterned after the Datagram interface, I called it a Cangram :-) The problem was how to cancel a read as part of a detected protocol or controller error. The hardware was reset via the native code driver which released resources so a restart was successful. I may have garbaged a thread and started a new one as part of it. > > You said later, `a way for a waiting state in native code to > be forced to exit in a reliable, detectable, manner'. Sounds > complicated :) Is this a generic requirement? I think, protocols > often can be implemented to use InputStream (or some other > interface) but also to offer the same interface (like the > decorator pattern). At least when `stacking' such protocols it > can become quite difficult, even if having an own thread per > protocol instance. Of course heavily depends on the project and > situation. Well, interesting topic :) > I think it (reset, stop, interrupt, whatever) should be a general requirement for any Java native interface code. Without it, your application can lock up and there is no reasonable way to regain control. > > The protocols timeout event handler reset the CAN controller to > > get it into a known state for a retry. The reset caused an IO > > exception to the waiting read thread which could check that a > > timeout had caused it. > > Ohh, the CAN controller must be reset? Though they would handle a > whole frame automatically. > I have no clue about this; surely it is very specific and complex. > The native interface resets it. In most cases, the only reason to reset it was so the native interface was freed up for a retry. If they had a interrupt() function, that may have been better. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. > This message may contain confidential and/or privileged information. If > you are not the addressee or authorized to receive this for the addressee, > you must not use, copy, disclose or take any action based on this message or > any information herein. If you have received this message in error, please > advise the sender immediately by reply e-mail and delete this message. Thank > you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/7df09a1e/attachment-0004.html From beat.arnet at gmail.com Mon May 18 13:27:07 2009 From: beat.arnet at gmail.com (Beat Arnet) Date: Mon, 18 May 2009 15:27:07 -0400 Subject: [Rxtx] Error 0x3e3 at termios.c(1301) Message-ID: All, I am experiencing a situation in which RXTX crashes consistently (both with 2.1 and 2.2). Steps to reproduce: - computer with JAVA program is sending bytes over RS-232 to embedded device, embedded device is off - embedded device powers up and transmit startup banner - JVM crashes: Error 0x3e3 at termios.c(1301) Any idea of what I should be looking for? Thanks! Beat # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6163696c, pid=808, tid=9648 # # Java VM: Java HotSpot(TM) Client VM (1.6.0-b105 mixed mode) # Problematic frame: # C 0x6163696c # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x0af7e400): JavaThread "Thread-4" [_thread_in_native, id=9648] siginfo: ExceptionCode=0xc0000005, reading address 0x6163696c Registers: EAX=0xffffffff, EBX=0x78652064, ECX=0x7c90f661, EDX=0x00000005 ESP=0x0c68f990, EBP=0x70706120, ESI=0x6f207469, EDI=0x6e612072 EIP=0x6163696c, EFLAGS=0x00010206 Top of Stack: (sp=0x0c68f990) 0x0c68f990: 6e6f6974 71657220 74736575 0a0a0d2e 0x0c68f9a0: 00000000 0c68f9d4 6d94556c 0daa3cb4 0x0c68f9b0: 74697277 74794265 3e0d2065 0a000a3e 0x0c68f9c0: 7c90cfea 7c80a059 000007d4 0af7e400 0x0c68f9d0: 6d909d8d 000007d4 00000002 6d945bf6 0x0c68f9e0: 0af7e400 00000001 00000000 0af8b024 0x0c68f9f0: 00000032 0af8b038 00000002 00000000 0x0c68fa00: 00000000 0af7e400 0af8b02c 06e85900 Instructions: (pc=0x6163696c) 0x6163695c: [error occurred during error reporting, step 100, id 0xc0000005] Stack: [0x0c640000,0x0c690000), sp=0x0c68f990, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C 0x6163696c [error occurred during error reporting, step 120, id 0xc0000005] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeByte(IZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write(I)V+86 j codeskin.serial.SerialPortRxtx2_1.write(I)V+29 j codeskin.c2oooprog.BootLoader2xxx$PingTask.run()V+87 v ~StubRoutines::call_stub -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/a692f306/attachment-0004.html From cowwoc at bbs.darktech.org Mon May 18 15:43:15 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Mon, 18 May 2009 17:43:15 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <4A119FC1.3090700@trustcommerce.com> Message-ID: <4A11D673.7080508@bbs.darktech.org> I'm in favor of using SerialPortChannel for timeouts and InputStream for non-blocking reads. This will allow us to follow the specification to the letter without any funky side-effects. In my view breaking the InputStream specification is a far greater sin than throwing InterruptedIOException from read(). Using SerialPortChannel and InputStream should allow us to please people in both camps without breaking the specification. Gili Bill Johnson wrote: > Hi Johnny, > > I think a SerialPortChannel could be a good example. It uses an > underlying Socket which uses an underlying implementation to support > open, timeouts, etc. As part of the implementation is where the current > RXTX could come in, provided there is a way to back out of a blocking > situation. > > +BillJ > > On Mon, May 18, 2009 at 1:49 PM, Johnny Luong > > > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Bill Johnson wrote: > | I can add this thought, I think the timeout is part of a protocol, > which > | should sit above RXTX. > > ... > > > Hi Bill, > > This is all conjecture and probably a lot of work in practice, so its > just a train of thought at this point (via NIO)... > > Supposer SerialPort were to implement a method that returned > "SerialPortChannel" which worked along similar lines as a SocketChannel. > ~ Then you could in practice, have a Selector object that did the > timeout > you described above (via a register method)... your read and write > methods could block or not block and it would be a lot easier to drive > multiple serial ports than what you have today. > > - -Johnny > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkoRn8EACgkQnQTBLXttTeXm0gCfaua0ej3Rt0fogRR68bbEFG0Z > BTwAn1s79U8ZU0yj6xcND8gyHzDmKKqq > =ThWj > -----END PGP SIGNATURE----- > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From bschlining at gmail.com Mon May 18 21:20:25 2009 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 18 May 2009 20:20:25 -0700 Subject: [Rxtx] Fwd: image capture In-Reply-To: References: Message-ID: forgot to cc the list ---------- Forwarded message ---------- From: Brian Schlining Date: Mon, May 18, 2009 at 20:19 Subject: Re: [Rxtx] image capture To: "Dr. Douglas Lyon" > Is anyone able to do image capture on a 64 bit mac, using > Java? Yes, I'm doing it from both video capture cards (Kona and Blackmagic) as well as from movie files. I'm only doing it on Java 5 (Mac) though. > QT4J is not loadable using Java 6 (AFAIK). Are you running this on a Mac or PC? Not that it matters I guess. QT4J is (unofficially) dead. It will be officially deprecated when Mac OS X 10.6 (Snow Leopard) is released, but for all practical purposes it's passed away. With each new release of QuickTime in the past year, I do the mad scramble to work around all the changes and bugs that are introduced. I'm working on once such 'fix' right now as a matter of fact. It's too bad too, QT4J was pretty darn powerful. Your best bet going forward is to rip out the QT4J code and replace it with a Mac/PC/Linux abstraction layer. On a Mac there you could try rococoa ( https://rococoa.dev.java.net) or just grab some QTKit samples off of Apples' developer site and write a JNI or JNA interface. On a PC, not sure what to tell you. I don't know what Apple's plans are with QT4J on a PC. They are pushing everyone away from QuickTime (C API) to QTKit (Cocoa/Objective-C). But on a PC ASFAIK there is no QTKit, so it's still QuickTime in the key of C. -- B ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/913800a4/attachment-0004.html From Kustaa.Nyholm at planmeca.com Tue May 19 00:26:27 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 19 May 2009 09:26:27 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A11D673.7080508@bbs.darktech.org> Message-ID: Oops, did it again, did not send this to the list, so we go: > > I'm in favor of using SerialPortChannel for timeouts and InputStream > for non-blocking reads. This will allow us to follow the specification > to the letter without any funky side-effects. > It was not clear to me what Gili is advocating here so I felt I needed to clarify this. > > In my view breaking the InputStream specification is a far greater sin > than throwing InterruptedIOException from read(). Throwing InterruptedIOException from InputStream.read() is just as big sin as it breaks the contract of InterruptedIOException , which says that the *thread* that was performing the IO was interrupted. Coneceptually I feel throwing an exception is a big sin in a situation which is not an error. A time out in a serial communication is almost always to be excepted since it is used to deal with real, live hardware outside the computer and very often it is a part of the higher level communication protocol, for example used to package or frame messages. Exceptions should be reserved for exceptional things not used for something that the programmer expects to happen normally. For one thing they incur an overhead. Granted, in a typical 9600 baud ie 1ms/char case the overhead is negligible, but it is there. On my 2.8 GHz Core 2 Duo try/throw/catch takes about 13 usec. In my view it is simply wrong to throw an exception for timeouts in a serial port. An even greater sin would be breaking existing code for design purity, at least in this case. > Using > SerialPortChannel and InputStream should allow us to please people in > both camps without breaking the specification. > So you are advocating adding a new class SerialPortChannel and a new method SerialPort.getSerialPortChannel() ? That would be acceptable in that it would not brake existing code but totally unnecessary in my view. I suspect most people turn to rxtx as a replacement for javacomm and are only interested in getting the job done. And the current API does this with very nicely. I think we all have better use for our time than to re-invent a serial port API. If the API bothers someone, I suggest they write a wrapper to implement the improvements and release it for interested users, if any. Would be kind of fun to see them struggle with all the API design issues and see what intellectual compromises they have to concede to. As a famous film ends in the sentence: "Nobody's perfect." cheers Kusti From Steffen.DETTMER at ingenico.com Tue May 19 02:12:14 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 19 May 2009 10:12:14 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A11D673.7080508@bbs.darktech.org> Message-ID: <20090519081214.GY17036@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Tue, May 19, 2009 at 09:26 +0300: > Coneceptually I feel throwing an exception is a big sin in a situation > which is not an error. Yes, I think the same. > In my view it is simply wrong to throw an exception for timeouts in > a serial port. Yes, I agree! > An even greater sin would be breaking existing code for design > purity, at least in this case. An even greater sin than that IMHO would be if the new stuff still isn't undoubtful powerful (which would IMHO need to include the possibility to select serial, TCP and other files simultaneously on systems that support it, e.g. for multi-serial-console applications or so). > So you are advocating adding a new class SerialPortChannel and > a new method SerialPort.getSerialPortChannel() ? SerialPortChannel would be a java.nio.channels.SelectableChannel or so? Or maybe a AbstractGatheringInterruptibleSelectableReadableWritableByteChannel. (the java name for `int fd' lol - SCNR). If changeing, I think an option could be to implement straightforward in native code offering its natural API (full timeout support, maybe as mandatory parameter, not dealing with Channel, Streams, source&sink, reactor&proactor patterns :-)). On top of that then both Channel and Stream and maybe something else for someone else. > That would be acceptable in that it would not brake existing code but > totally unnecessary in my view. I suspect most people turn to rxtx > as a replacement for javacomm and are only interested in getting the > job done. Yes, and most probably just have a few simultaneous connections. Others may need to have a dedicated, specialized and highly optimized JNI impl anyway (I guess). > If the API bothers someone, I suggest they write a wrapper to > implement the improvements and release it for interested users, > if any. Yes, actually that was what we did, but sometimes it was a bit cumbersome (because of InputStream and stuff). We implemented on top of that (instead of native interfaces or such) assuming that those interfaces won't change (but JNI interfaces probably are considered implementation details and thus probably will change). > Would be kind of fun to see them struggle with all the API > design issues and see what intellectual compromises they have > to concede to. Yeah, and then a nio successor comes and everone wanna go with it then :-) oki, Steffen ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Tue May 19 02:33:35 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 19 May 2009 10:33:35 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> Message-ID: <20090519083335.GZ17036@elberon.bln.de.ingenico.com> Hi! * Bill Johnson wrote on Mon, May 18, 2009 at 15:24 -0400: > * On Mon, May 18, 2009 at 1:54 PM, Steffen DETTMER wrote: > > * Bill Johnson wrote on Mon, May 18, 2009 at 13:08 -0400: > > > I can add this thought, I think the timeout is part of a > > > protocol, which should sit above RXTX. > > > > Probably actually on both levels timeouts can be helpful; if > > there is some PPP/TCP or other full duplex multiplexing > > protcol I think at least it is nice to be able to read with > > some reasonable timeout(s). > > I think timeout at the native level does not fit well with a > read() concept of timeout because it depends on the protocol > not really on the read(). What is special about `native level' to gain a special handling? I think all levels should support timeouts. Of course the read timeout an application invokes on a TCP stream has no direct relation to a PPP timeout and intercharacter timeouts on serial lines often depend on serial speed, CPU speed, required response timings, interrupt load etc, I think. So yes, I agree that protocols (often) define needed timeouts (to the lower layer) and the lower layer must offer support for timeouts. Is this what you mean with `depends on the protocol'? > > (this Bosch car protocol?) > > > > But if the protocol implementation knows the timeout value, > > wouldn't it be easier and suited better to have some way to apply > > it to the reads without needing multithreading? > > If you are waiting on a read and you are waiting on a timeout at the same > time, that is two logical threads. Ohh no, I disagree. I think, only if you have plenty of resources it is possible to waste a whole thread to watch a clock. When you have to read 100 connections of course you can use 100 threads, but better would be 1 thread with a select (or epoll or whatever), especially when assuming that the timeout is just a wait (thread sleep) time (when the OS is buffering the data anyway, which on Java running OSes probably is common). > Maybe you are looping check for one of two condition, character > or timeout, but I think its the same logically as waiting for a > character or a timeout exception. It is a special case where > you try to read except if it take too long, sound a little like > code? But isn't a maximum time a natural property of waiting? When you wait for someone for a meeting or so, you look to your watch from time to time and after half an hour or so you leave or continue your business. Select style IMHO is logically more event based than multi-threaded synchronous, but for applications or protocol implementations I found it comfortable when timeouts can be configured at any time. We even have two optional timeout parameters on our read function which eases implementing requirements like `receive both characters within 200 ms or reply with X'. > The CAN bus was Java on a TINI embedded system for a warehouse > system. It implemented a guaranteed delivery data path > patterned after the Datagram interface, I called it a Cangram > :-) The problem was how to cancel a read as part of a detected > protocol or controller error. The hardware was reset via the > native code driver which released resources so a restart was > successful. I may have garbaged a thread and started a new one > as part of it. cool :-) guess this was a very interesting project :) > I think it (reset, stop, interrupt, whatever) should be a > general requirement for any Java native interface code. Without > it, your application can lock up and there is no reasonable way > to regain control. alternatively, it could be required that any JNI function must return after some latest amount of time (i.e. specifying the maximum invocation time). I think, third-path-interruptions, maybe triggered from different threads, could quickly make code complicated because suddenly so many possible code paths can happen and they are hard to test (and cover). Personally, I think this is a major point against avoidable thread usage (even more if threads are not orthogonal) - hard to test, hard to ensure and prove it really is wrong always. Of course often enough it is needed anyway... oki, Steffen ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From michaeltandy at googlemail.com Tue May 19 08:33:09 2009 From: michaeltandy at googlemail.com (Michael Tandy) Date: Tue, 19 May 2009 15:33:09 +0100 Subject: [Rxtx] Rxtx native library loading Message-ID: <302aa0340905190733r4009e394v335b3ef47d84ffb5@mail.gmail.com> Attached is a patch which changes native library loading in Rxtx. Specifically, it makes two changes: 1. Looks in the directory RXTXcomm.jar is in for a native library, prior to searching java.library.path 2. Produces more informative error messages (in addition to the normal exceptions) if the native library cannot be found. The key benefits of this are: (a) to simplify setup; no need for administrator access to put things in shared/system directories, just unzip a file (containing my program as a .jar, RXTXcomm.jar, rxtxSerial.dll, librxtxSerial.so, and so on) and you're good to go; (b) If you've got multiple rxtx versions on your path (e.g. MATLAB puts its bin directory on your path, containing a copy of rxtxSerial.dll) you get the library file matching your jar file; (c) you don't need a big -Djava.library.path= every time you start your program; (d) if your native library file is missing, the error message is a bit more helpful (tells you where is being searched and for what); and (e) If the new code fails, it reverts to what the old code did, so it should be fully backwards-compatible. What do you think - is it worth including these changes in the main version of rxtx? Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: libraryloader.diff Type: text/x-diff Size: 10293 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090519/641c6573/attachment-0003.bin From bill7007 at gmail.com Tue May 19 12:37:32 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Tue, 19 May 2009 14:37:32 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090519083335.GZ17036@elberon.bln.de.ingenico.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> <20090519083335.GZ17036@elberon.bln.de.ingenico.com> Message-ID: On Tue, May 19, 2009 at 4:33 AM, Steffen DETTMER wrote: ... > > Is this what you mean with `depends on the protocol'? Native code is run time speed efficient, and that is important. I think I am saying, design wise, the function is read(). Timeout is a condition on read() only required by whatever comm protocol or comm logic you are using. I am thinking the whole purpose of SerialPort object is to represent a serial port so it should only contains methods and attributes of a serial port. A timeout is an event, part of the communication logic that is using that port. Wow, what a discussion. I had to go back and read it all to gather thoughts. I see multiple issues here. They coexist. 1) CommPort timeout implementation 2) Native blocking behavior and possible interruptions I think my protocol timeout thought was to state that the CommPort timeout may not be the best way implement a protocol timeout, but an alternative needs a blocking interrupt capability. Maybe that should be its own discussion. I do agree with the commandment, Thou shalt not modify the reference API. To focus back on Sun's CommPort interface, it does define a timeout that is optionally implemented and could be useful. I think a description of CommPort.getInputStream together with InputStream.read() leads to the implementation behavior: read() returns "the next byte of data, or -1 if the end of the stream is reached." So, end of stream must mean one of: 1) a timeout 2) "framing errors" (plural meaning parity and overrun too?) read(byte[]?b) returns "the total number of bytes read into the buffer, or -1 is there is no more data because the end of the stream has been reached." An end of stream here causes a return of the number read so far, or -1 if no data was yet read. How to determine cause of end of stream is a weakness of this API. Capturing a SerialPortEvent includes the framing error but not timeout. +BillJ From Steffen.DETTMER at ingenico.com Tue May 19 13:10:26 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 19 May 2009 21:10:26 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> <20090519083335.GZ17036@elberon.bln.de.ingenico.com> Message-ID: <20090519191025.GF17036@elberon.bln.de.ingenico.com> * Bill Johnson wrote on Tue, May 19, 2009 at 14:37 -0400: > methods and attributes of a serial port. A timeout is an event, part > of the communication logic that is using that port. (or the absence of data arrived events?) > read() returns "the next byte of data, or -1 if the end of the stream > is reached." > So, end of stream must mean one of: > 1) a timeout > 2) "framing errors" (plural meaning parity and overrun too?) I think neither timeout nor framing errors are end of stream (end of file) but only `remote DTR drop' is. I'm not sure (and always confuse) to which input line its maps and whether it is hi or lo active... I think, on linux, at least some versions, this worked well because when one side called close(fd) the other side read the EOF in exactly this moment. In general I think this is not reliable (different OSes surely handle it differently and it probably depends on several other things). With TCP sockets this can be expected to work (when one side shuts down its write channel, the other reads EOF after reading all data, which of course is returned first). Well, but probably some OS out there will be different just to annoy us :-) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From cowwoc at bbs.darktech.org Tue May 19 14:28:36 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 19 May 2009 16:28:36 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <4A131674.6000906@bbs.darktech.org> Guys, I am feeling very frustrated with this whole discussion. 1) There is no doubt that the current implementation breaks the InputStream API. A return value of -1 is already mapped to end-of-stream. For this reason, you *cannot* map the same value to a timeout. This is basic design-by-contract! 2) RXTX's implementation does not match javax.comm 100%. There are plenty of situations where the two implementations diverge. I am frustrated that people want to simultaneously freeze the APIs and fix issues that *cannot* be fixed purely in the implementation layer. 3) "Premature optimization is the root of all evil" and yet I see people complaining that exception handling costs 13 usec. Java places emphasizes correctness above performance. If you don't get that you shouldn't be coding in Java. More specific replies below... > Throwing InterruptedIOException from InputStream.read() is just as > big sin as it breaks the contract of InterruptedIOException , which > says that the *thread* that was performing the IO was interrupted. A thread getting interrupted is not the same as Thread.interrupt(). My interpretation is that interrupting the operation due to a timeout is a perfectly legal form of "thread interruption". Even with respect to Thread.interrupt(), you can't interrupt a thread, only the work it is executing. > Coneceptually I feel throwing an exception is a big sin in a situation > which is not an error. Exceptions refer to "exceptional circumstances" which is not the same as "errors". By that I mean that the "normally" the method returns 0-255, but exceptional cases such as timeouts are perfectly legal. > A time out in a serial communication is > almost always to be excepted since it is used to deal with real, live > hardware outside the computer I disagree. Some application-level protocols don't use timeouts at all. Why would your argument be true for serial connections but not sockets? > So you are advocating adding a new class SerialPortChannel and > a new method SerialPort.getSerialPortChannel() ? > > That would be acceptable in that it would not brake existing code but > totally unnecessary in my view. I suspect most people turn to rxtx > as a replacement for javacomm and are only interested in getting the > job done. And the current API does this with very nicely. I think > we all have better use for our time than to re-invent a serial port > API. The classic IO api is synchronous whereas NIO channels are asynchronous. Trying to retrofit timeouts on top of the old APIs will never be as clean as using NIO which is designed specifically for this purpose. Gili From tjarvi at qbang.org Tue May 19 17:19:15 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 May 2009 17:19:15 -0600 (MDT) Subject: [Rxtx] Rxtx native library loading In-Reply-To: <302aa0340905190733r4009e394v335b3ef47d84ffb5@mail.gmail.com> References: <302aa0340905190733r4009e394v335b3ef47d84ffb5@mail.gmail.com> Message-ID: On Tue, 19 May 2009, Michael Tandy wrote: > Attached is a patch which changes native library loading in Rxtx. > > Specifically, it makes two changes: > > 1. Looks in the directory RXTXcomm.jar is in for a native library, > prior to searching java.library.path > 2. Produces more informative error messages (in addition to the normal > exceptions) if the native library cannot be found. > > The key benefits of this are: > (a) to simplify setup; no need for administrator access to put things > in shared/system directories, just unzip a file (containing my program > as a .jar, RXTXcomm.jar, rxtxSerial.dll, librxtxSerial.so, and so on) > and you're good to go; > (b) If you've got multiple rxtx versions on your path (e.g. MATLAB > puts its bin directory on your path, containing a copy of > rxtxSerial.dll) you get the library file matching your jar file; > (c) you don't need a big -Djava.library.path= every time you start your program; > (d) if your native library file is missing, the error message is a bit > more helpful (tells you where is being searched and for what); > and (e) If the new code fails, it reverts to what the old code did, so > it should be fully backwards-compatible. > > What do you think - is it worth including these changes in the main > version of rxtx? > > Michael > Hi Michael, We will be putting a patch like yours in as soon as we release 2.2. The release was going to be mothers day but I got caught up :) I hope to do it next weekend. After that we will be looking at web installs which overlaps with your solution. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 19 17:44:25 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 May 2009 17:44:25 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A131674.6000906@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> Message-ID: On Tue, 19 May 2009, cowwoc wrote: >> A time out in a serial communication is >> almost always to be excepted since it is used to deal with real, live >> hardware outside the computer > > I disagree. Some application-level protocols don't use timeouts at all. > Why would your argument be true for serial connections but not sockets? > Hi Gili One fundamental difference between sockets, file io and RS232 communication is that sockets and file systems provide error handling. If a packet is lost, it is resent without the java API knowing about it. RS232 is actually an electrical signal standard. Serial communication exposes a UART without any meaningful error handling and cludgy error reporting. Given the above, ignoring timeouts is not really a valid rxtx level option. We could have a new option/method that allows you to get an InputStream or Channel that behaves as you wish. If we change the InputStream returned by getInputStream(), that would be change in the API (version 3.0) that forks our userbase. So I guess my question is whether or not you are trying to change the object returned by getInputStream or just looking for a means to get a different object you would like to define be returned. The later is far easier to accommodate. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 19 18:38:06 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 May 2009 18:38:06 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090519191025.GF17036@elberon.bln.de.ingenico.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> <20090519083335.GZ17036@elberon.bln.de.ingenico.com> <20090519191025.GF17036@elberon.bln.de.ingenico.com> Message-ID: On Tue, 19 May 2009, Steffen DETTMER wrote: > * Bill Johnson wrote on Tue, May 19, 2009 at 14:37 -0400: >> methods and attributes of a serial port. A timeout is an event, part >> of the communication logic that is using that port. > > (or the absence of data arrived events?) > >> read() returns "the next byte of data, or -1 if the end of the stream >> is reached." >> So, end of stream must mean one of: >> 1) a timeout >> 2) "framing errors" (plural meaning parity and overrun too?) > > I think neither timeout nor framing errors are end of stream (end > of file) but only `remote DTR drop' is. I'm not sure (and always > confuse) to which input line its maps and whether it is hi or lo > active... > There really is an end of input in termios that would match up fairly close in theory. The problem is it isnt really used as far as I know. termois.c_cc[VEOF] - the end of input character. I assume it is control-d. If you have a terminal open, try typing it into the shell prompt :) We even have some access to it in rxtx as extensions to commapi: private native byte nativeGetEndOfInputChar( ) throws UnsupportedCommOperationException; private native boolean nativeSetEndOfInputChar( byte b ) throws UnsupportedCommOperationException; GPIB has an entire wire dedicated to "EOI." -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue May 19 19:07:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 19 May 2009 21:07:34 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> Message-ID: <4A1357D6.9090705@bbs.darktech.org> Hi Trent, > RS232 is actually an electrical signal standard. Serial communication > exposes a UART without any meaningful error handling and cludgy error > reporting. > > Given the above, ignoring timeouts is not really a valid rxtx level > option. We could have a new option/method that allows you to get an > InputStream or Channel that behaves as you wish. Why? You could always use available() alongside blocking reads. > If we change the InputStream returned by getInputStream(), that would be > change in the API (version 3.0) that forks our userbase. > > So I guess my question is whether or not you are trying to change the > object returned by getInputStream or just looking for a means to get a > different object you would like to define be returned. > > The later is far easier to accommodate. I expect users to use getInputStream() for blocking reads and getInputChannel() for non-blocking reads. I understand your objections and normally I'd agree to wait for version 3.0 but RXTX's violation of the specification is a critical flaw in my opinion. Don't take my word for it... Take a look at this post I just ran across: http://stackoverflow.com/questions/611760/java-inputstream-read-blocking ------ quote ------- A read of -1 isn't doesn't mean, "there's no data present on this attempt," it means, "the stream is closed and there will never be any data so stop asking." If the end of the stream has not been reached, a read() call will block, just as the documentation specifies. [...] I've only used javax.comm for serial port I/O, and it implements InputStream as intended. It's possible that the rxtx implementation violates the contract of InputStream.read(), but if so, that's a very bad thing. Any code that was written to work with InputStream in general relies on the fact that -1 means EOF. Passing a broken java.io.InputStream to such code will cause problems. If rxtx supports non-blocking I/O, they should have created their own interface for reading, not extended InputStream. ------ quote ------- We learn two things from this post: 1) javax.comm respects the InputStream contract. It does not return -1 on timeouts. Seeing how you've written that any deviation from the javax.comm implementation is a bug I would suggest that this should be fixed immediately. 2) Violating the superclass specification can introduce an untold number of bugs. For example, I spent hours trying to figure out why BufferedReader.readLine() was returning null while the connection was still open. Gili From tjarvi at qbang.org Tue May 19 19:23:13 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 May 2009 19:23:13 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A1357D6.9090705@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> Message-ID: On Tue, 19 May 2009, cowwoc wrote: > > 1) javax.comm respects the InputStream contract. It does not return -1 on > timeouts. Seeing how you've written that any deviation from the javax.comm > implementation is a bug I would suggest that this should be fixed > immediately. > Hi Gili What is the observed behavior of javax.comm on timeout? Are you sure it didn't just disable timeouts by default? -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue May 19 19:37:24 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 19 May 2009 21:37:24 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> Message-ID: <4A135ED4.3090608@bbs.darktech.org> Trent Jarvi wrote: >> 1) javax.comm respects the InputStream contract. It does not return -1 >> on timeouts. Seeing how you've written that any deviation from the >> javax.comm implementation is a bug I would suggest that this should be >> fixed immediately. > What is the observed behavior of javax.comm on timeout? Are you sure it > didn't just disable timeouts by default? I'm not sure. Unfortunately, I've never gotten javax.comm to work under Windows and I don't have access to any other platform at this time. I assume that you've used javax.comm before, so I encourage you to try it on your end. Whatever they did, I really don't think that Sun would have violated the InputStream specification by returning -1 on timeout. As the BufferedReader.readLine() example shows, doing so triggers a lot of bugs. Gili From tjarvi at qbang.org Tue May 19 20:01:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 May 2009 20:01:53 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A135ED4.3090608@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> <4A135ED4.3090608@bbs.darktech.org> Message-ID: On Tue, 19 May 2009, cowwoc wrote: > Trent Jarvi wrote: >>> 1) javax.comm respects the InputStream contract. It does not return -1 on >>> timeouts. Seeing how you've written that any deviation from the javax.comm >>> implementation is a bug I would suggest that this should be fixed >>> immediately. > >> What is the observed behavior of javax.comm on timeout? Are you sure it >> didn't just disable timeouts by default? > > I'm not sure. Unfortunately, I've never gotten javax.comm to work > under Windows and I don't have access to any other platform at this time. I > assume that you've used javax.comm before, so I encourage you to try it on > your end. Whatever they did, I really don't think that Sun would have > violated the InputStream specification by returning -1 on timeout. As the > BufferedReader.readLine() example shows, doing so triggers a lot of bugs. > I've actually never used the Sun implementation. RXTX and CommAPI have very different origins that overlap with Kevin Hester's "JCL" patch to bring them together. The rest has been done from the docs. Default settings have always been a source of confusion which is why I ask. Disabled timeouts/thresholds would behave like you expect. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue May 19 20:30:22 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 19 May 2009 22:30:22 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> <4A135ED4.3090608@bbs.darktech.org> Message-ID: <4A136B3E.7010704@bbs.darktech.org> Trent Jarvi wrote: > What is the observed behavior of javax.comm on timeout? Are you sure > it didn't just disable timeouts by default? Can someone who has used javax.comm please investigate this and let us know? Thanks, Gili From Steffen.DETTMER at ingenico.com Wed May 20 02:30:08 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 20 May 2009 10:30:08 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A131674.6000906@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> Message-ID: <20090520083008.GH17036@elberon.bln.de.ingenico.com> * cowwoc wrote on Tue, May 19, 2009 at 16:28 -0400: > Guys, I am feeling very frustrated with this whole discussion. (Me too, but probably for different reason :-)) > 1) There is no doubt that the current implementation breaks the > InputStream API. (which must happen, because InputStream as defined is less usable) > A return value of -1 is already mapped to end-of-stream. For > this reason, you *cannot* map the same value to a timeout. This > is basic design-by-contract! Currently (actually we are still using RXTX-2.1-7 which surely isn't the latest version :)), in case of timeout read(byte[]) returns 0. We have a wrapper implementation (which because of some rxtx timeout precision issues) might be a few lines more than needed but provides timeout precision typical better than 100ms (for us, this is sufficient). I wrote about it here some years ago. So it's possible to work with rxtx even with InputStream. Not very comfortable thanks for InputStream, but it works. Java developers expect InputStream (with its limitations). I was told this several times. May the java and javax APIs suck or not, but it is what most java developers are used to use, expect and what we live with in so many other areas, too. > 2) RXTX's implementation does not match javax.comm 100%. There > are plenty of situations where the two implementations diverge. > I am frustrated that people want to simultaneously freeze the > APIs and fix issues that *cannot* be fixed purely in the > implementation layer. As already written, I think a `real complete exhaustive fix' isn't possible or desired here for various reasons. The current way works well and complies to java stuff as much as possible (the differences are enforced logically and the InputStream specification IMHO is simply wrong). Now why change, requiring people to redevelop their applications or wrappers? Why not alternatively publish one of those wrappers (yours? :-)) under a public license and/or add it to rxtx allowing people that want exceptions allowing them to use configurable exceptions (for example)? > 3) "Premature optimization is the root of all evil" and yet I > see people complaining that exception handling costs 13 usec. > Java places emphasizes correctness above performance. If you > don't get that you shouldn't be coding in Java. In general, also `oversimplification is a root of evil' and IMHO nice examples can be found in Java APIs, but this is the way `everyone' goes. Raping exceptions as return codes IMHO is not a performance problem but a design problem (in a non-RAII-aware language which is not allowing ensured resource cleanups by guaranteed destructors this is a real big problem, IMHO). I don't understand the discussion. We have a read returning number of bytes read. We have situations where no byte is read. Now the API doesn't tell that in this case zero should be returned, but I think this is so damn obvious, isn't it?? > > A time out in a serial communication is almost always to be > > excepted since it is used to deal with real, live hardware > > outside the computer > > I disagree. Some application-level protocols don't use timeouts > at all. Why would your argument be true for serial connections > but not sockets? In general, everything has (or should have) timeouts /or/ be under control of something. Technically, the latter may require use `timeouts in a loop' (some polling). TCP has timeouts, for instance retransmission timeouts. Situations were no timeouts are defined in TCP (was it e.g. FIN_WAIT?) in the past lead to issues. On real OSes there are also UDP sockets, UNIX Domain Sockets and whatever else - and all of them and serial ports can accessed via one and the same API and select'd at the same time: timeout supported is simply built-in. For complex protcols, like TCP, all the heaps of defined timeouts might not be as visible as for serial case, where typical applications handle details themself, but they exist. > The classic IO api is synchronous whereas NIO channels are > asynchronous. Trying to retrofit timeouts on top of the old > APIs will never be as clean as using NIO which is designed > specifically for this purpose. I think classic is BSD socket API, which IMHO looks like a natural evolution of classic unix APIs. Works also for serial and everything (at least on unix and cygwin). I think Java people didn't saw the big picture and tried to simplify but oversimplified, assuming, InputStream could be used for all types of communication. Actually, it even can, but not alone (usually, you additionally need OutputStream and some ioctl). Now of course it was nice and sexy to critise the non-type-safe ioctl and select and to drop it - but this of course is no solution. Just ignoring the difficulties rarely helps. NIO is a bit more BSD socket API style, a step into the direction where everything comes from. Next version might take another step and reach the goal. Who knows. As far as I know none of the issues that lead to NIO (mostly performance and scalability) apply to rxtx. The only thing that seems to appy is that some buggy Javadoc tells InputStream would be blocking, available has no timeout, write timeouts are also not supported - and read(byte[]) never returns 0. Which quickly, easily and straightforward `fixes' the issues. That is what rxtx did. Isn't this fine? oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From m.j.tandy at warwick.ac.uk Wed May 20 03:01:51 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 20 May 2009 10:01:51 +0100 Subject: [Rxtx] InputStream timeouts In-Reply-To: <302aa0340905200201r912d9d0m6c9e1e41e049f1df@mail.gmail.com> References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> <302aa0340905200201r912d9d0m6c9e1e41e049f1df@mail.gmail.com> Message-ID: <302aa0340905200201t13a31a4bq30f60042c50fde63@mail.gmail.com> > 2) Violating the superclass specification can introduce an untold number > of bugs. For example, I spent hours trying to figure out why > BufferedReader.readLine() was returning null while the connection was > still open. We're discussing what the read() method does on timeout - but isn't the failure of BufferedReader.readLine caused by read(byte[] b, int off, int len) returning '0 bytes read' - not caused by what the read() method does on timeout? I mean, when I run the code below (Java 1.6.0_13-b03 / Sun JDK 6) the output is: Attempting to read a line... program called inputstream's read(byte[] b, int off, int len) java.io.IOException: Underlying input stream returned zero bytes ? ? ? ?at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) ? ? ? ?at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) ? ? ? ?at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) ? ? ? ?at java.io.InputStreamReader.read(InputStreamReader.java:167) ? ? ? ?at java.io.BufferedReader.fill(BufferedReader.java:136) ? ? ? ?at java.io.BufferedReader.readLine(BufferedReader.java:299) ? ? ? ?at java.io.BufferedReader.readLine(BufferedReader.java:362) ? ? ? ?at inputstreamtest.Main.main(Main.java:14) And if I look at the source code for StreamDecoder.java [1] I see the following lines: ?283 ? ? ? ? ? ? ? int n = in.read(bb.array(), bb.arrayOffset() + pos, rem); ?284 ? ? ? ? ? ? ? if (n < 0) ?285 ? ? ? ? ? ? ? ? ? return n; ?286 ? ? ? ? ? ? ? if (n == 0) ?287 ? ? ? ? ? ? ? ? ? throw new IOException("Underlying input stream returned zero bytes"); Which kind of makes sense, because the javadoc for read(byte[] b, int off, int len) [2] does explicitly say that "If len is zero, then no bytes are read and 0 is returned; otherwise, there is an attempt to read at least one byte. If no byte is available because the stream is at end of file, the value -1 is returned; otherwise, at least one byte is read and stored into b." Is this the problem that you encountered? Michael [1] http://www.docjar.com/html/api/sun/nio/cs/StreamDecoder.java.html [2] http://java.sun.com/javase/6/docs/api/java/io/InputStream.html#read(byte[],%20int,%20int) // CODE BEGINS HERE package inputstreamtest; import java.io.BufferedReader; import java.io.IOException; import java.io.InputStream; import java.io.InputStreamReader; public class Main { ? ?public static void main(String[] args) { ? ? ? ?BufferedReader in = new BufferedReader(new InputStreamReader(new FakeInputStream())); ? ? ? ?System.out.println("Attempting to read a line..."); ? ? ? ?try { ? ? ? ? ? ?in.readLine(); ? ? ? ?} catch (IOException e) { ? ? ? ? ? ?e.printStackTrace(); ? ? ? ?} ? ?} ? ?private static class FakeInputStream extends InputStream { ? ? ? ?@Override ? ? ? ?public int read(byte[] b, int off, int len) { ? ? ? ? ? ?System.out.println("program called inputstream's read(byte[] b, int off, int len)"); ? ? ? ? ? ?return 0; ? ? ? ?} ? ? ? ?@Override ? ? ? ?public int read() throws IOException { ? ? ? ? ? ?System.out.println("program called inputstream's read()"); ? ? ? ? ? ?return -1; ? ? ? ?} ? ?} } From Steffen.DETTMER at ingenico.com Wed May 20 03:16:20 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 20 May 2009 11:16:20 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> <20090519083335.GZ17036@elberon.bln.de.ingenico.com> <20090519191025.GF17036@elberon.bln.de.ingenico.com> Message-ID: <20090520091620.GI17036@elberon.bln.de.ingenico.com> * Trent Jarvi wrote on Tue, May 19, 2009 at 18:38 -0600: > >I think neither timeout nor framing errors are end of stream (end > >of file) but only `remote DTR drop' is. I'm not sure (and always > >confuse) to which input line its maps and whether it is hi or lo > >active... > > There really is an end of input in termios that would match up > fairly close in theory. The problem is it isnt really used as > far as I know. > > termois.c_cc[VEOF] - the end of input character. I assume it > is control-d. If you have a terminal open, try typing it into > the shell prompt :) Ahh yes, this way it was! (what means `logged out' and why my modem has no carrier?! :)) With a null modem cable and a C++ implementation I tried it and found that you are right, it is working with ^D (but not with DTR as I claimed), thanks for the correction. In `stty raw' ^D is 0x04 but after `stty sane' ^D works as end of input character, as you said. select(2) tells ready for read and read(2) return 0 bytes, which means EOF :-) (Well, in strict pure theory I think this could be considered a property of the terminal line discipline canonical mode, which IMHO could be considered a protocol property) BTW, is someone using this EOF in general? Our C++ implementation supports both it seems it (EOF detection) was never used. I guess it depends on the domain someone is working in? I could imagine that some micro controller control interfaces use that? oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed May 20 03:32:00 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 20 May 2009 11:32:00 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> <20090519083335.GZ17036@elberon.bln.de.ingenico.com> <20090519191025.GF17036@elberon.bln.de.ingenico.com> Message-ID: <20090520093200.GK17036@elberon.bln.de.ingenico.com> ps. our java implementation using RXTX-2.1-7 (surely very old) does not detect the ^D in `stty sane' mode. also, just BTW, about the IOException interruption discussion. When I aborted the java command line test program by ^C, I got IOException: java.io.IOException: Interrupted system call in readArray which IMHO shows that Kusti is right. The code not detecting EOF is similar to: port_.enableReceiveTimeout(intTimeout); bytesRead = port_.getInputStream().read( buffer, totalBytesRead, bytesRequested ); switch (bytesRead) { case -1: readClosedByPeer_ = true; break; case 0: // log interchar timeout if (totalBytesRead > 0) { rs232Logger_.finest( "Intercharacter timeout (" + getByteReadTimeout() + " ms) while reading, might be Ok. Returning " + totalBytesRead + " bytes read so far" ); } if (!ENABLE_RECEIVE_TIMEOUT_PRECISION_LOGGING) { break; } So actually I don't know if readClosedByPeer ever worked (we don't use it anyway I think). oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Wed May 20 03:57:30 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 12:57:30 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <302aa0340905200201t13a31a4bq30f60042c50fde63@mail.gmail.com> Message-ID: > From: Michael Tandy > And if I look at the source code for StreamDecoder.java [1] I see the > following lines: > ?283 ? ? ? ? ? ? ? int n = in.read(bb.array(), bb.arrayOffset() + pos, rem); > ?284 ? ? ? ? ? ? ? if (n < 0) > ?285 ? ? ? ? ? ? ? ? ? return n; > ?286 ? ? ? ? ? ? ? if (n == 0) > ?287 ? ? ? ? ? ? ? ? ? throw new IOException("Underlying input stream > returned zero bytes"); > > Which kind of makes sense, because the javadoc for read(byte[] b, int > off, int len) [2] does explicitly say that "If len is zero, then no > bytes are read and 0 is returned; otherwise, there is an attempt to > read at least one byte. If no byte is available because the stream is > at end of file, the value -1 is returned; otherwise, at least one byte > is read and stored into b." Not realy relevant for the discussion but out of curiosity I had peek at the code you quoted and just a few lines above we see: 278 int lim = bb.limit(); 279 int pos = bb.position(); 280 assert (pos <= lim); 281 int rem = (pos <= lim ? lim - pos : 0); 282 assert rem > 0; If asserts are disabled (the default IIRC) then 'rem' could be 0 in which case throwing exception on line 287 is not correct in that it is legal for read(byte[]) to return under that circumstance. Of course it maybe that the design of StreamDecoder otherwise guarantees that lim > pos but this just shows how difficult it is to be logically consistent all the time. Further browsing the StreamDecoder and CharsetDecorder classes it seems, at least superficially, that nothing has been gained by checking and throwing an exception, the rest of code would have worked correctly even if the the read on line 283 would return 0. All code that I've ever written have handled read(byte[]) returning 0 correctly (touch wood!) taking it on it's stride. Why not, you need to prepare for read to return less than what you asked so it naturally falls to handle the case of 0 also. From Kustaa.Nyholm at planmeca.com Wed May 20 04:06:12 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 13:06:12 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090520083008.GH17036@elberon.bln.de.ingenico.com> Message-ID: > From: Steffen DETTMER > >> 1) There is no doubt that the current implementation breaks the >> InputStream API. > (which must happen, because InputStream as defined is less usable) > Exactly. > Now why change, requiring people to redevelop their applications > or wrappers? Why not alternatively publish one of those wrappers > (yours? :-)) under a public license and/or add it to rxtx > allowing people that want exceptions allowing them to use > configurable exceptions (for example)? > Hear,hear, agree whole heartedly! > > I don't understand the discussion. We have a read returning > number of bytes read. We have situations where no byte is read. > Now the API doesn't tell that in this case zero should be > returned, but I think this is so damn obvious, isn't it?? To me it is soooooo obvious. > > The only thing that seems to appy is that some buggy Javadoc > tells InputStream would be blocking, available has no timeout, > write timeouts are also not supported - and read(byte[]) never > returns 0. Which quickly, easily and straightforward `fixes' the > issues. That is what rxtx did. Isn't this fine? It is fine. It ain't broken, don't fix it. This is mainly a documentation issue. When the map and scenery disagree trust the scenery. Thanks Steffen for summing it up so nicely! cheers Kusti From cowwoc at bbs.darktech.org Wed May 20 04:39:31 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 06:39:31 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090520083008.GH17036@elberon.bln.de.ingenico.com> References: <4A131674.6000906@bbs.darktech.org> <20090520083008.GH17036@elberon.bln.de.ingenico.com> Message-ID: <4A13DDE3.8070703@bbs.darktech.org> Steffen DETTMER wrote: > * cowwoc wrote on Tue, May 19, 2009 at 16:28 -0400: >> Guys, I am feeling very frustrated with this whole discussion. > > (Me too, but probably for different reason :-)) > >> 1) There is no doubt that the current implementation breaks the >> InputStream API. > > (which must happen, because InputStream as defined is less usable) Not true. Either we follow the InputSteam specification or we define our own interface. Breaking the specification in this way will trigger unpredictable bugs. > Currently (actually we are still using RXTX-2.1-7 which surely > isn't the latest version :)), in case of timeout read(byte[]) > returns 0. > > I don't understand the discussion. We have a read returning > number of bytes read. We have situations where no byte is read. > Now the API doesn't tell that in this case zero should be > returned, but I think this is so damn obvious, isn't it?? Actually, the Javadoc for read(byte[]) says that at least one byte must be read: "If the length of b is zero, then no bytes are read and 0 is returned; otherwise, there is an attempt to read at least one byte. If no byte is available because the stream is at the end of the file, the value -1 is returned; otherwise, at least one byte is read and stored into b." > In general, everything has (or should have) timeouts /or/ be > under control of something. Technically, the latter may > require use `timeouts in a loop' (some polling). TCP has > timeouts, for instance retransmission timeouts. Situations were > no timeouts are defined in TCP (was it e.g. FIN_WAIT?) in the > past lead to issues. On real OSes there are also UDP sockets, > UNIX Domain Sockets and whatever else - and all of them and > serial ports can accessed via one and the same API and select'd > at the same time: timeout supported is simply built-in. > For complex protcols, like TCP, all the heaps of defined timeouts > might not be as visible as for serial case, where typical > applications handle details themself, but they exist. Fair enough, but "timeouts in a loop" -- using available() -- don't break the InputStream specification. > NIO is a bit more BSD socket API style, a step into the direction > where everything comes from. Next version might take another step > and reach the goal. Who knows. As far as I know none of the > issues that lead to NIO (mostly performance and scalability) > apply to rxtx. NIO allows you to select() on a channel with a timeout, which is the point of contention. > The only thing that seems to appy is that some buggy Javadoc > tells InputStream would be blocking, available has no timeout, > write timeouts are also not supported - and read(byte[]) never > returns 0. Which quickly, easily and straightforward `fixes' the > issues. That is what rxtx did. Isn't this fine? I'm not sure I understand. I get that you dislike that InputStream doesn't provide facilities for non-blocking reads but that is just life. You're supposed to either create your own interface or use NIO for that. In my view, breaking the superclass contract is always worse than inconveniencing yourself. Gili From cowwoc at bbs.darktech.org Wed May 20 04:41:14 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 06:41:14 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <302aa0340905200201t13a31a4bq30f60042c50fde63@mail.gmail.com> References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> <302aa0340905200201r912d9d0m6c9e1e41e049f1df@mail.gmail.com> <302aa0340905200201t13a31a4bq30f60042c50fde63@mail.gmail.com> Message-ID: <4A13DE4A.70704@bbs.darktech.org> Yes. Gili Michael Tandy wrote: >> 2) Violating the superclass specification can introduce an untold number >> of bugs. For example, I spent hours trying to figure out why >> BufferedReader.readLine() was returning null while the connection was >> still open. > > We're discussing what the read() method does on timeout - but isn't > the failure of BufferedReader.readLine caused by read(byte[] b, int > off, int len) returning '0 bytes read' - not caused by what the read() > method does on timeout? > > I mean, when I run the code below (Java 1.6.0_13-b03 / Sun JDK 6) the output is: > > Attempting to read a line... > program called inputstream's read(byte[] b, int off, int len) > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > at inputstreamtest.Main.main(Main.java:14) > > And if I look at the source code for StreamDecoder.java [1] I see the > following lines: > 283 int n = in.read(bb.array(), bb.arrayOffset() + pos, rem); > 284 if (n < 0) > 285 return n; > 286 if (n == 0) > 287 throw new IOException("Underlying input stream > returned zero bytes"); > > Which kind of makes sense, because the javadoc for read(byte[] b, int > off, int len) [2] does explicitly say that "If len is zero, then no > bytes are read and 0 is returned; otherwise, there is an attempt to > read at least one byte. If no byte is available because the stream is > at end of file, the value -1 is returned; otherwise, at least one byte > is read and stored into b." > > Is this the problem that you encountered? > > Michael > > [1] http://www.docjar.com/html/api/sun/nio/cs/StreamDecoder.java.html > [2] http://java.sun.com/javase/6/docs/api/java/io/InputStream.html#read(byte[],%20int,%20int) > > > // CODE BEGINS HERE > package inputstreamtest; > > import java.io.BufferedReader; > import java.io.IOException; > import java.io.InputStream; > import java.io.InputStreamReader; > > public class Main { > > public static void main(String[] args) { > BufferedReader in = new BufferedReader(new > InputStreamReader(new FakeInputStream())); > System.out.println("Attempting to read a line..."); > try { > in.readLine(); > } catch (IOException e) { > e.printStackTrace(); > } > } > > private static class FakeInputStream extends InputStream { > @Override > public int read(byte[] b, int off, int len) { > System.out.println("program called inputstream's > read(byte[] b, int off, int len)"); > return 0; > } > > @Override > public int read() throws IOException { > System.out.println("program called inputstream's read()"); > return -1; > } > } > > } > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From cowwoc at bbs.darktech.org Wed May 20 04:45:25 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 06:45:25 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <4A13DF45.7030305@bbs.darktech.org> Kustaa Nyholm wrote: > It is fine. It ain't broken, don't fix it. This is mainly > a documentation issue. When the map and scenery disagree trust > the scenery. This isn't "documentation". It's a specification. The core Java APIs implement it perfectly and expect it to be followed 100% of the time. It is impossible to change it this late in the game. Gili From Kustaa.Nyholm at planmeca.com Wed May 20 06:03:15 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 15:03:15 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A131674.6000906@bbs.darktech.org> Message-ID: > > Guys, I am feeling very frustrated with this whole discussion. I feel your pain as I'm frustrated, not by the discussion which has been conducted in a gentlemanly maner and has entertained me quite a lot, but by people trying to fix what ain't broken. > > 1) There is no doubt that the current implementation breaks the > InputStream API. Well, this is like saying my car is broken because a mouse ate the registration paper (honestly, that happened last winter). There is only a very minor discrepancy between what a few document sentences says and what *useful and practical* functionality the current rxtx/javacomm provides. > A return value of -1 is already mapped to > end-of-stream. For this reason, you *cannot* map the same value to a > timeout. This is basic design-by-contract! I thought we already agreed (talking about read(byte[])) 0 should be returned and AFAIK *is* returned. And this matches the javadoc for CommPort.getInputStream() which says that it return a kind of InputStream where read operations blocks until a timeout occurs OR until any data is available. So it can return even when no data is available. And in that case 0 seems like an appropriate return value. It bends the rules of InputStream a bit, but this is by design, not error. Now, if read() returns -1 in case of timeout this is a dilemma as it does allow differentiation between EOF (whatever it means for serial stream) and timeout. However the 'golden standard', the stream object that javacomm.SerialPort.getInputStream().read(), returns in case of timeout is -1, at least on Windows (just tested it). And we should not brake this compatibility. > > 2) RXTX's implementation does not match javax.comm 100%. > So? Why make it match even less? Most people want compatibility and usability, not semantic / logical correctness at least as far as something as small as serial port API is concerned. Go write your own wrapper if it bother you. > There are > plenty of situations where the two implementations diverge. If there are, please let us know, this is very useful information for any rxtx user so that they can avoid these pitfalls. > I am > frustrated that people want to simultaneously freeze the APIs and fix > issues that *cannot* be fixed purely in the implementation layer. What issues you mean? Off hand I don't recall people asking for fixes that would match your description of "that *cannot* be fixed purely in the implementation layer". Personally, all I've ever wanted from javacomm and rxtx was to be able to access the serial port from Java in platform neutral fashion that allows my code to run on the three major platforms Mac OS X, Linux and Windows. And rxtx delivers just that. > > 3) "Premature optimization is the root of all evil" and yet I see people > complaining that exception handling costs 13 usec. I'm sure you understood that 13 usec was not the point. The point is that exception handling concept has been designed to handle exceptional case which are rare and thus performance of the code when an exception is thrown can be slow. The penalty is not specified but includes creating a new object or several (stack trace) and frequently warned about. Like I said, and I'm sure you understood, at 9600 baud this penalty is not an issue, but in a slower machine (mine was, as stated 2.8 GHz/4GB/1066MHz Core 2 Duo), or different JVM, or JIT not happening (BTW exception handling disturbs JIT) it could be a decade slower. So make it 100 usec and raise baud rate to 1 MBps now merely throwing the exception takes ten times longer than a one character timeout. Many protocols I have programmed have used pauses of less than that to frame messages. IMO it would be serious mistake to use exceptions to handle timeouts. Ever wondered why EOF is signaled with -1 and not an exception... > Java places > emphasizes correctness above performance. If you don't get that you > shouldn't be coding in Java. This is not what I would call parliamentary language. I won't reply. > > More specific replies below... > >> Throwing InterruptedIOException from InputStream.read() is just as >> big sin as it breaks the contract of InterruptedIOException , which >> says that the *thread* that was performing the IO was interrupted. > > A thread getting interrupted is not the same as Thread.interrupt(). Oh yeah? Really? In the context it was used I beg to differ. > My interpretation is that interrupting the operation due to a timeout is a > perfectly legal form of "thread interruption". Even with respect to > Thread.interrupt(), you can't interrupt a thread, only the work it is > executing. > >> Coneceptually I feel throwing an exception is a big sin in a situation >> which is not an error. > > Exceptions refer to "exceptional circumstances" which is not the same > as "errors". By that I mean that the "normally" the method returns > 0-255, but exceptional cases such as timeouts are perfectly legal. But timeout with SerialPort usually is not an exceptional case. But I guess you are fixed to your idea that it is. The important thing however is that it is not for me or you to decide and thus it is not for the API to dictate this. > >> A time out in a serial communication is >> almost always to be excepted since it is used to deal with real, live >> hardware outside the computer > > I disagree. Some application-level protocols don't use timeouts at > all. > Why would your argument be true for serial connections but not sockets? What Sockets and application level protocols have got to do with reading a SerialPort/RS232 port and it's timeouts? > >> So you are advocating adding a new class SerialPortChannel and >> a new method SerialPort.getSerialPortChannel() ? >> >> That would be acceptable in that it would not brake existing code but >> totally unnecessary in my view. I suspect most people turn to rxtx >> as a replacement for javacomm and are only interested in getting the >> job done. And the current API does this with very nicely. I think >> we all have better use for our time than to re-invent a serial port >> API. > > The classic IO api is synchronous whereas NIO channels are > asynchronous. Trying to retrofit timeouts on top of the old APIs will > never be as clean as using NIO which is designed specifically for this > purpose. > You maybe right, but the cure is worse than the disease and the first rule of a good doctor is to "do no harm". What you are concerned about is some semantic details what most of us are concerned with is getting the job done. Here are some more thoughts on using exceptions in case you can be bothered. Quoting from Sun's exception handling tutorial: http://java.sun.com/docs/books/tutorial/essential/exceptions/throwing.html "An Exception indicates that a problem occurred" Now, a timeout, to me, is not a problem, but very often an essential part of the communication protocol. Of course for some in some situations it maybe a problem, but that is not for the (communication) API designer to decide or dictate. To me this spells that timeouts should not throw an exception. Also from the same document: "Here's the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception." Following this guideline would dictate that timeout exception should be a checked exception (because surely almost universally the programmer who enables timeouts (disable by default, remember) can and will handle the timeouts in some reasonable way. *Adding a checked exception toInputStream.reads is not possible.* Again this speaks against throwing an exception in case of timeouts. More in the same vein: http://developer.apple.com/documentation/Performance/Conceptual/CodeSpeed/Ar ticles/TuningJavaCode.html#//apple_ref/doc/uid/TP40002329-DontLinkElementID_ 4 "Exception handling in Java is very slow. ... use exceptions only for truly exceptional cases. Do not use exceptions to indicate simple errors from which your code could otherwise recover. Instead, use them only to indicate abnormal conditions that your code does not know how to handle." cheers Kusti From Kustaa.Nyholm at planmeca.com Wed May 20 06:20:34 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 15:20:34 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A13DDE3.8070703@bbs.darktech.org> Message-ID: > > Not true. Either we follow the InputSteam specification or we define > our own interface. Breaking the specification in this way will trigger > unpredictable bugs. Well bugs are by their very nature unpredictable, what? But seriously who are you to dictate "high road or low road"? Who says we (whoever that 'we' are) must either follow 100% or define our own? If 'we' want to take a middle road we surely can. And I'm all for it. Pursuing 100% clean designs is a fruitless goal and I've got better things to do than keep updating my code base to track an ever changing API in pursuit of an unattainable internal and external purity and correctness. > > Fair enough, but "timeouts in a loop" -- using available() -- don't > break the InputStream specification. So why not use it? If you do not touch the enableTimeout() and enableThreshold() methods the SerialPort.InputStream fulfills the contract to the letter. And if you touch them, it fulfills the commitment that creators of the original API made. > You're supposed to either create your own interface or use NIO for that. > In my view, breaking the superclass contract is always worse than > inconveniencing yourself. Why don't you provide a proof of concept framework of classes and interfaces that are internally and externally consistent for us to scrutinize? I bet it will contain one or two compromises and bending of the rules or be totally out of tune what people need or want to use. cheers Kusti From Steffen.DETTMER at ingenico.com Wed May 20 07:23:40 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 20 May 2009 15:23:40 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A13DDE3.8070703@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> <20090520083008.GH17036@elberon.bln.de.ingenico.com> <4A13DDE3.8070703@bbs.darktech.org> Message-ID: <20090520132339.GB27170@elberon.bln.de.ingenico.com> * cowwoc wrote on Wed, May 20, 2009 at 06:39 -0400: > >>1) There is no doubt that the current implementation breaks the > >>InputStream API. > > > >(which must happen, because InputStream as defined is less usable) > > Not true. Either we follow the InputSteam specification or we define > our own interface. Breaking the specification in this way will trigger > unpredictable bugs. First, I disagree that it is specification because it actually is documentation. A specification would also need to specify how overloaded methods are allowed to change without violating the specification. If javadoc in general would be no documentation but specification obviously no overloaded method could specialise or change any behavior, because as soon as documentation of an overloaded would be needed, it would violate base class specification, in short, no new specification (documentation) could be allowed in any subclass. Theoretically this could be a point (an option to develop a language) but I think it makes not much sense in practice. Also, it often happens that even in specifications there are obvious issues, as soon as everyone does the obvious thing, instead of changing all implementations, the specification is fixed. Or left as it is :) Of course we define an own interface by deriving (implementing) InputStream because specifics will happen. For instance specialised exceptions may be thrown in special new situations not documented (specified) by InputStream. This is what OO is for I think. :) > Actually, the Javadoc for read(byte[]) says that at least one > byte must be read: "If the length of b is zero, then no bytes > are read and 0 is returned; otherwise, there is an attempt to > read at least one byte. If no byte is available because the > stream is at the end of the file, the value -1 is returned; > otherwise, at least one byte is read and stored into b." Strictly speaking, at least for me with my limited foreign language English knowledge, it does not tell what happens if an attempt to read at least one byte was done, no byte was available, the stream is NOT at the end of the file, but still no byte was read. I would accept the point that, strictly speaking, InputStream unconditionally forbids any timeout support (except polling available(), which at least sucks). This actually was my initial point. This prohibition makes no sense and probably was just done by accident (otherwise, docu should tell this) and also is violated if throwing exceptions and also is violated by Java stuff itself. > Fair enough, but "timeouts in a loop" -- using available() -- > don't break the InputStream specification. Yes, and somewhere probably there is some guy who defined InputStream as an Aprils Fool Joke and now cannot sleep because laughing about all those people that poll available() all the time (no delay to gain response time) wasting all CPU resources :-) Anyway, since years InputStream is used and I don't think we can do anything against. I also don't like it, but that's life. If you want a nice language use C++ or Ruby or so ;) SCNR. > >NIO is a bit more BSD socket API style, a step into the direction > >where everything comes from. Next version might take another step > >and reach the goal. Who knows. As far as I know none of the > >issues that lead to NIO (mostly performance and scalability) > >apply to rxtx. > > NIO allows you to select() on a channel with a timeout, which > is the point of contention. Yes, but not if the channel is some InputStream like STDIN, right? Also, as far as I know, you cannot select on own things. So wouldn't work for serial lines or protocols. I think you cannot implement TCP via PPP reasonable and efficiently in (pure) Java, even with NIO as far as I know this is not possible. But there are many things in Java that you cannot implement in Java (even String!). A pitty but otherwise things would be horrible slow. > I'm not sure I understand. I get that you dislike that > InputStream doesn't provide facilities for non-blocking reads > but that is just life. You're supposed to either create your > own interface or use NIO for that. In my view, breaking the > superclass contract is always worse than inconveniencing > yourself. I think, when we would discuss NIO, we would also quickly find sufficient issues with it (I think we had this discussion already) and that we do not (really :)) break the superclass contract (of InputStream). We just add possibility to support timeout (by new method setReceiveTimeout() and overloaded read()). :-) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed May 20 07:40:03 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 20 May 2009 15:40:03 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> Message-ID: <20090520134002.GC27170@elberon.bln.de.ingenico.com> (OT) * Kustaa Nyholm wrote on Wed, May 20, 2009 at 15:03 +0300: > Ever wondered why EOF is signaled with -1 and not an exception... Yeah... I always wonder why Java has so many issues that were already discussed and solved since ages in POSIX or ANSI-C or C++ /before/ java was started. On POSIX reads -1 is error. You call some select(2) before. If select tells ready-for-read and you read EOF, read returns 0 bytes. This is at least a bit intuitive - and seems to work in all cases. Seeing a file descriptor like a class IMHO works. read(fd, ..) could be understood as fd.read(). When looking how great in overall this works I feel deep respect for all the people who invented that :) > > Java places emphasizes correctness above performance. This is definitely wrong. Much of Java Core Tech is uglyDirtyNasty because of performance. For instance you cannot overload String (reasonable). Operator overloading is not possible except for String.operator+ (concatenation). Implicite conversion is possible by Object().toString() but nowhere else. You cannot implement a toLong() and have it be called implicitely. String automatically uses StringBuffer for operations, again a hack you have no chance to copy or influence. You cannot pass scalars like long by reference, you are force to pass them by value. You cannot pass Objects by value, you are forced to pass them by reference. Except your object is e.g. a Long, then it is passed by value. You cannot implement any of that in Java itself. It is Mr. JVM in person :) who knows those hacks and how to workaround / pass by. Also great is Object.clone(). Works without overloading. How does Object.clone() know the members of the child class? Because it knows the structure and hacks it to match. Same for serialisation and deserialisation. Object construction. Why can an Object call a method overloaded in a child class in its constructor? Interesting is what happens: the child class is already `half constructed', i.e. working except member initialisation and its constructor was not run. But a method can be invoked. This is not clean this sucks but anyway. We could continue this quite some time (Inner Class hacks, Generics hacks, forced GC, no RAII support would be next) :-) Honestly, a student would not pass a university test with so much hacking (I hope ;)). oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From michael.erskine at ketech.com Wed May 20 07:45:13 2009 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 20 May 2009 14:45:13 +0100 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0D6BA5.8020209@bbs.darktech.org> References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <06BA3262D918014F9183B66425D5A8D463C3C2E90A@no-sv-03.ketech.local> I wander in to find a gazillion posts about whether RXTX is breaking some rule or other. I don't have time to read and argue the toss over which way of doing something may be more correct. As far as I'm concerned (and, I venture, the other developers in industry) whatever RXTX does _IS_ the right thing. I don't fancy trying to justify the costs that would be incurred in the respecifying, rewriting, and retesting of an absolute ton of SIL2 software. Please, let's not screw things up. Regards, Michael Erskine. From Kustaa.Nyholm at planmeca.com Wed May 20 07:58:12 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 16:58:12 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090520134002.GC27170@elberon.bln.de.ingenico.com> Message-ID: Just to clarify Steffen's mail, this was not my sentence: >>> Java places emphasizes correctness above performance. to which he responded: > > This is definitely wrong. Much of Java Core Tech is > uglyDirtyNasty because of performance. > > Honestly, a student would not pass a university test with so much > hacking (I hope ;)). > and with which I agree. cheers Kusti From Kustaa.Nyholm at planmeca.com Wed May 20 08:13:54 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 17:13:54 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <06BA3262D918014F9183B66425D5A8D463C3C2E90A@no-sv-03.ketech.local> Message-ID: Michael Erskine: > I wander in to find a gazillion posts about whether RXTX is breaking some rule > or other. I don't have time to read and argue the toss over which way of doing > something may be more correct. I've participated in the discussion just for that reason, trying to prevent anyone 'correcting' this API. > > As far as I'm concerned (and, I venture, the other developers in industry) > whatever RXTX does _IS_ the right thing. Indeed! > > I don't fancy trying to justify the costs that would be incurred in the > respecifying, rewriting, and retesting of an absolute ton of SIL2 software. > Hear, hear! > Please, let's not screw things up. Yeah, let's not screw this up. From cowwoc at bbs.darktech.org Wed May 20 08:40:11 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 10:40:11 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090520132339.GB27170@elberon.bln.de.ingenico.com> References: <4A131674.6000906@bbs.darktech.org> <20090520083008.GH17036@elberon.bln.de.ingenico.com> <4A13DDE3.8070703@bbs.darktech.org> <20090520132339.GB27170@elberon.bln.de.ingenico.com> Message-ID: <4A14164B.6040000@bbs.darktech.org> Steffen DETTMER wrote: > First, I disagree that it is specification because it actually is > documentation. A specification would also need to specify how > overloaded methods are allowed to change without violating the > specification. If javadoc in general would be no documentation > but specification obviously no overloaded method could specialise > or change any behavior, because as soon as documentation of an > overloaded would be needed, it would violate base class > specification, That is incorrect. Design by Contract allows subclasses to weaken preconditions, strengthen postconditions and strengthen invariants -- all without violating the superclass specification. > Also, it often happens that even in specifications there are > obvious issues, as soon as everyone does the obvious thing, > instead of changing all implementations, the specification is > fixed. Or left as it is :) As far as I know, this has never been done for core Java classes because doing so would break backwards compatibility. This is discussed at length in the Effective Java book. > Of course we define an own interface by deriving (implementing) > InputStream because specifics will happen. For instance > specialised exceptions may be thrown in special new situations > not documented (specified) by InputStream. This is what OO is for > I think. :) A subclass may not throw any new (checked) exceptions. Doing so would violating the superclass specification. You could always throw a subclass of IOException but that's about it. The reason this only applies to checked exceptions is that all methods throw RuntimeException by default. >> Actually, the Javadoc for read(byte[]) says that at least one >> byte must be read: "If the length of b is zero, then no bytes >> are read and 0 is returned; otherwise, there is an attempt to >> read at least one byte. If no byte is available because the >> stream is at the end of the file, the value -1 is returned; >> otherwise, at least one byte is read and stored into b." > > Strictly speaking, at least for me with my limited foreign > language English knowledge, it does not tell what happens if an > attempt to read at least one byte was done, no byte was > available, the stream is NOT at the end of the file, but still no > byte was read. The sentence above reads "This method blocks until input data is available, end of file is detected, or an exception is thrown." In other words, you must block. > I would accept the point that, strictly speaking, InputStream > unconditionally forbids any timeout support (except polling > available(), which at least sucks). > > This actually was my initial point. This prohibition makes no > sense and probably was just done by accident (otherwise, docu > should tell this) and also is violated if throwing exceptions and > also is violated by Java stuff itself. If a timeout could be said to be a new kind of end-of-stream (with the resulting behavior being absolutely identical) then using -1 might be fine. Unfortunately, this is not the case. End-of-stream indicates that the InputStream will never return bytes ever again. Timeouts violate this guarantee. With respect to exceptions, you are allowed to throw any subclass of IOException for the reasons mentioned in Design by Contract. >> Fair enough, but "timeouts in a loop" -- using available() -- >> don't break the InputStream specification. > > Yes, and somewhere probably there is some guy who defined > InputStream as an Aprils Fool Joke and now cannot sleep because > laughing about all those people that poll available() all the > time (no delay to gain response time) wasting all CPU resources > :-) InputStream works perfectly fine for synchronous reading. If you want asynchronous reading you are supposed to use NIO channels. >> NIO allows you to select() on a channel with a timeout, which >> is the point of contention. > Yes, but not if the channel is some InputStream like STDIN, > right? Also, as far as I know, you cannot select on own things. > So wouldn't work for serial lines or protocols. I don't understand what you mean. You can get a Channel for System.in using java.nio.channels.Channels. > I think you cannot implement TCP via PPP reasonable and > efficiently in (pure) Java, even with NIO as far as I know this > is not possible. But there are many things in Java that you > cannot implement in Java (even String!). You can find TCP/PPP implementations in Java on the web. You don't need them most of the time because the OS provides an implementation for free. > I think, when we would discuss NIO, we would also quickly find > sufficient issues with it (I think we had this discussion > already) and that we do not (really :)) break the superclass > contract (of InputStream). We just add possibility to support > timeout (by new method setReceiveTimeout() and overloaded read()). Again, I suggest you read up on Design by Contract. You will find out exactly why you are not allowed to overload the -1 return code in this way. Gili From cowwoc at bbs.darktech.org Wed May 20 08:46:08 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 10:46:08 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <06BA3262D918014F9183B66425D5A8D463C3C2E90A@no-sv-03.ketech.local> References: <4A0D6BA5.8020209@bbs.darktech.org> <06BA3262D918014F9183B66425D5A8D463C3C2E90A@no-sv-03.ketech.local> Message-ID: <4A1417B0.3040903@bbs.darktech.org> Michael, You have a choice to either break compatibility with old versions of RXTX or break compatibility with all other libraries in existence. Both options suck, but the latter involves breaking even more code. Right now you cannot safely pass RXTX's InputStream into any other library in existence. Gili Michael Erskine wrote: > I wander in to find a gazillion posts about whether RXTX is breaking some rule or other. I don't have time to read and argue the toss over which way of doing something may be more correct. > > As far as I'm concerned (and, I venture, the other developers in industry) whatever RXTX does _IS_ the right thing. > > I don't fancy trying to justify the costs that would be incurred in the respecifying, rewriting, and retesting of an absolute ton of SIL2 software. > > Please, let's not screw things up. > > Regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From johnny.luong at trustcommerce.com Wed May 20 09:55:03 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Wed, 20 May 2009 08:55:03 -0700 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> Message-ID: <4A1427D7.2020906@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Trent Jarvi wrote: | On Tue, 19 May 2009, cowwoc wrote: |>> A time out in a serial communication is |>> almost always to be excepted since it is used to deal with real, live |>> hardware outside the computer |> I disagree. Some application-level protocols don't use timeouts at all. |> Why would your argument be true for serial connections but not sockets? |> | | Hi Gili | | One fundamental difference between sockets, file io and RS232 | communication is that sockets and file systems provide error handling. | If a packet is lost, it is resent without the java API knowing about it. | | RS232 is actually an electrical signal standard. Serial communication | exposes a UART without any meaningful error handling and cludgy error | reporting. | | Given the above, ignoring timeouts is not really a valid rxtx level | option. We could have a new option/method that allows you to get an | InputStream or Channel that behaves as you wish. | | If we change the InputStream returned by getInputStream(), that would | be change in the API (version 3.0) that forks our userbase. | | So I guess my question is whether or not you are trying to change the | object returned by getInputStream or just looking for a means to get a | different object you would like to define be returned. | | The later is far easier to accommodate. | | -- | Trent Jarvi | tjarvi at qbang.org | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Trent, For sockets, I'm not so sure there is really any guarantees short of actually monitoring it externally. For example, write() in outputstream doesn't return any value whatsoever -- you might get an exception but in the worse case, it just tells you something bad happened and in the best case, you might be able to catch some implementation specific exception. ~ The same could apply to files too but the magnitude of failure there are significantly lower. But this is sort of a digression... My thinking is that we just sort of keep the interface so that we don't disrupt people who use the methods (our software actually polls from the serial port version of the InputStream/OutputStream as a side effect of the quirkyness involved with the timeout -- this is because the USB-serial thing we had to work with really sucks) but add an additional interface similar to what is SocketChannel and proceed from there. There is a lot of work involved in it though and as it has been pointed out by others, maybe most can live with the hacks involved in the current implementation. Best, Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoUJ9cACgkQnQTBLXttTeVYlQCfcvIHMh1W1kcna5vUtg20dWWK flMAn2WZk03PSgYT1KkHMLp8TlLRtcxn =YeMI -----END PGP SIGNATURE----- From michaeltandy at googlemail.com Wed May 20 09:57:36 2009 From: michaeltandy at googlemail.com (Michael Tandy) Date: Wed, 20 May 2009 16:57:36 +0100 Subject: [Rxtx] Rxtx native library loading In-Reply-To: References: <302aa0340905190733r4009e394v335b3ef47d84ffb5@mail.gmail.com> Message-ID: <302aa0340905200857v53642f58je6932c3315b8a30d@mail.gmail.com> There's also a bug in my code; it worked fine swapping between my Windows machine and my 64-bit Linux machine, but trying to run the 64-bit library on my 32-bit Linux laptop (obviously) doesn't work. So, it needs to detect more architectures and handle them more cleverly :) Still, if your next release will do that, I guess I don't have to fix my code :) Thanks Michael 2009/5/20 Trent Jarvi : > > Hi Michael, > > We will be putting a patch like yours in as soon as we release 2.2. ?The > release was going to be mothers day but I got caught up :) ?I hope to do it > next weekend. ?After that we will be looking at web installs which overlaps > with your solution. > > -- > Trent Jarvi > tjarvi at qbang.org > From cowwoc at bbs.darktech.org Wed May 20 10:04:32 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 12:04:32 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A1427D7.2020906@trustcommerce.com> References: <4A131674.6000906@bbs.darktech.org> <4A1427D7.2020906@trustcommerce.com> Message-ID: <4A142A10.1090302@bbs.darktech.org> Johnny Luong wrote: > My thinking is that we just sort of keep the interface so that we don't > disrupt people who use the methods (our software actually polls from the > serial port version of the InputStream/OutputStream as a side effect of > the quirkyness involved with the timeout -- this is because the > USB-serial thing we had to work with really sucks) but add an additional > interface similar to what is SocketChannel and proceed from there. We could also deprecate getInputStream() in favor of another method that returns a fixed implementation. This will allow existing code to keep on working while providing a migration route for RXTX 3.0. Gili From jerrypedersen at telus.net Wed May 20 10:10:00 2009 From: jerrypedersen at telus.net (Jerry Pedersen) Date: Wed, 20 May 2009 09:10:00 -0700 Subject: [Rxtx] 38400 Baud - UnsupportedCommOperationexception: Invalid Parameter Message-ID: <4A142B58.4050909@telus.net> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090520/0ac89fb9/attachment-0002.html From bill7007 at gmail.com Wed May 20 11:20:13 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Wed, 20 May 2009 13:20:13 -0400 Subject: [Rxtx] 38400 Baud - UnsupportedCommOperationexception: Invalid Parameter In-Reply-To: <4A142B58.4050909@telus.net> References: <4A142B58.4050909@telus.net> Message-ID: Hi Jerry, You might check out: [Rxtx] Baud rate fixes in 2.2pre2 breaks 38400 on some Linux devices It has a link to a patch on 2.2pre that got me around a similar problem. +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090520/046aa29d/attachment-0002.html From Kustaa.Nyholm at planmeca.com Wed May 20 12:23:41 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 21:23:41 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A1417B0.3040903@bbs.darktech.org> References: <4A0D6BA5.8020209@bbs.darktech.org> <06BA3262D918014F9183B66425D5A8D463C3C2E90A@no-sv-03.ketech.local>, <4A1417B0.3040903@bbs.darktech.org> Message-ID: <5D23E5B41156B646B2E1A7C2BBA916F317119151AF@SRVFIHKIEXB01.pmgroup.local> Gili wrote: >You have a choice to either break compatibility with old versions of >RXTX or break compatibility with all other libraries in existence. Both >options suck, but the latter involves breaking even more code. Or, the third option, leave it well alone! Keep it compatible existing code that is actually using rxtx instead of just worrying about it being correct to a T. Use it as the creators meant it to be used. Stop worrying about this. > Right now you cannot safely pass RXTX's InputStream into any other >library in existence. Now that is blatantly untrue. If timeouts are not enable you can pass it safely to any library. When timeouts are enabled *some* libraries will not work, some will. If you worry or encounter such a situation you can then do some wrapper magic. But for pete's sake, let us not disturb the happy life of rxtx users with well intentioned but misguided zealozy. I wonder too how often SerialPort input stream is passed to *any* library? I certainly haven't done that ever. The way I vision people are using serial port is to talk directly to it doing most if not all of the protocol handling with custom code, not with a library. If pass it (the input stream) to a library that chokes on read returning 0 it is rather your fault for not reading what the javadoc for SerialPort.getInputStream says! cheers Kusti From tjarvi at qbang.org Wed May 20 17:18:37 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 May 2009 17:18:37 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A142A10.1090302@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> <4A1427D7.2020906@trustcommerce.com> <4A142A10.1090302@bbs.darktech.org> Message-ID: On Wed, 20 May 2009, cowwoc wrote: > Johnny Luong wrote: >> My thinking is that we just sort of keep the interface so that we don't >> disrupt people who use the methods (our software actually polls from the >> serial port version of the InputStream/OutputStream as a side effect of >> the quirkyness involved with the timeout -- this is because the >> USB-serial thing we had to work with really sucks) but add an additional >> interface similar to what is SocketChannel and proceed from there. > > We could also deprecate getInputStream() in favor of another method > that returns a fixed implementation. This will allow existing code to > keep on working while providing a migration route for RXTX 3.0. > Hi Gili, Good. I think it is time to see the method and InputStream. From there, we can discuss options in 3.0. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Wed May 20 18:49:50 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 20:49:50 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> <4A1427D7.2020906@trustcommerce.com> <4A142A10.1090302@bbs.darktech.org> Message-ID: <4A14A52E.7080701@bbs.darktech.org> Trent Jarvi wrote: > Good. > > I think it is time to see the method and InputStream. From there, we > can discuss options in 3.0. I propose the following: 1) add "CommPortChannel getChannel()" 2) deprecate getInputStream() and enableReceiveTimeout() in favor of getChannel() 3) getChannel() will return a class that implements the same interfaces as SocketChannel. It will allow both blocking and non-blocking I/O operations. 4) In RXTX 3.0 getInputStream() will return an InputStream that always blocks on reads and the method will be undeprecated. Gili From tjarvi at qbang.org Wed May 20 19:27:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 May 2009 19:27:50 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A14A52E.7080701@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> <4A1427D7.2020906@trustcommerce.com> <4A142A10.1090302@bbs.darktech.org> <4A14A52E.7080701@bbs.darktech.org> Message-ID: On Wed, 20 May 2009, cowwoc wrote: > Trent Jarvi wrote: >> Good. >> >> I think it is time to see the method and InputStream. From there, we can >> discuss options in 3.0. > > I propose the following: > > 1) add "CommPortChannel getChannel()" > 2) deprecate getInputStream() and enableReceiveTimeout() in favor of > getChannel() > 3) getChannel() will return a class that implements the same interfaces as > SocketChannel. It will allow both blocking and non-blocking I/O operations. > 4) In RXTX 3.0 getInputStream() will return an InputStream that always blocks > on reads and the method will be undeprecated. > Hi Gili, RXTX 3.0 would be the soonest we would start any deprecation if it is agreed upon. So far, I don't think there is near enough buy in. But you can have getChannel now. If it is obviously a right solution, you may see people reconsider their opinions. Timeouts wont go away or be deprecated but they could throw unsupported io exceptions for the life of the inputstream returned by getChannel for obvious reasons. Let people try it and give feedback. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Thu May 21 01:19:05 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 21 May 2009 10:19:05 +0300 Subject: [Rxtx] InputStream timeouts Message-ID: <5D23E5B41156B646B2E1A7C2BBA916F317119151B4@SRVFIHKIEXB01.pmgroup.local> Hi Gili, please don't start patronizing. I've been around OO and Design by Contract from around 1986 starting by implementing our own Smalltalk environment. By then I had been writing software for ten years. It is not that I don't understand what you are saying. It is just that I'm not (any more ?!) an OO or DbC zealot. In real world most concepts seem to break down when applied over too wide field. Newtons laws are fine until you get to quantum level. OO is great, but at least so far, it seems that making everything (think integers) objects was a mistake in Smalltalk. You maybe right on the theoretical level, but who cares? Who are you to impose *your* standards on the rest of us? *Every good desing is a compromize.* In this instance I'm 100% sure that the designers of javacomm were well aware of the issues you are complaining about and considered these and many other issues. And their compromise is what we have today.It would belittling them to think otherwise. And to me, even if I think I see where you are coming from, the compromise seem almost perfect for the given problem. To me it is very natural and works almost perfectly despite (or because ?) of the little bending of the rules. Like Steffen(?) wrote here earlier : that (compromise to make it work) is Java all over. And I firmly believe that that is what made Java a success, just like C. Not the prettiest girls in town but very popular... cheers Kusti ________________________________________ From: cowwoc [cowwoc at bbs.darktech.org] Sent: Wednesday, May 20, 2009 9:42 PM To: Kustaa Nyholm Subject: Re: [Rxtx] InputStream timeouts Do me a favor and let me know once you read about Design by Contract. Only then will you be able to understand why RXTX cannot redefine how InputStream works. If subclasses are allowed to modify the contract in an arbitrary manner it defeats the entire concept of Class Inheritance and formal Interfaces. Gili Kustaa Nyholm wrote: > Gili wrote: > >> You have a choice to either break compatibility with old versions of >> RXTX or break compatibility with all other libraries in existence. Both >> options suck, but the latter involves breaking even more code. > > Or, the third option, leave it well alone! Keep it compatible existing code > that is actually using rxtx instead of just worrying about it being correct > to a T. Use it as the creators meant it to be used. Stop worrying about > this. > > >> Right now you cannot safely pass RXTX's InputStream into any other >> library in existence. > > Now that is blatantly untrue. If timeouts are not enable you can pass > it safely to any library. When timeouts are enabled *some* libraries will > not work, some will. If you worry or encounter such a situation you > can then do some wrapper magic. But for pete's sake, let us not disturb > the happy life of rxtx users with well intentioned but misguided zealozy. > > I wonder too how often SerialPort input stream is passed to *any* library? > > I certainly haven't done that ever. > > The way I vision people are using serial port is to talk directly to it > doing most if not all of the protocol handling with custom code, > not with a library. If pass it (the input stream) to a library that chokes on > read returning 0 it is rather your fault for not reading what > the javadoc for SerialPort.getInputStream says! > > cheers Kusti > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Kustaa.Nyholm at planmeca.com Thu May 21 01:20:42 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 21 May 2009 10:20:42 +0300 Subject: [Rxtx] InputStream timeouts Message-ID: <5D23E5B41156B646B2E1A7C2BBA916F317119151B5@SRVFIHKIEXB01.pmgroup.local> Gili wrote: >You have a choice to either break compatibility with old versions of >RXTX or break compatibility with all other libraries in existence. Both >options suck, but the latter involves breaking even more code. Or, the third option, leave it well alone! Keep it compatible existing code that is actually using rxtx instead of just worrying about it being correct to a T. Use it as the creators meant it to be used. Stop worrying about this. > Right now you cannot safely pass RXTX's InputStream into any other >library in existence. Now that is blatantly untrue. If timeouts are not enable you can pass it safely to any library. When timeouts are enabled *some* libraries will not work, some will. If you worry or encounter such a situation you can then do some wrapper magic. But for pete's sake, let us not disturb the happy life of rxtx users with well intentioned but misguided zealozy. I wonder too how often SerialPort input stream is passed to *any* library? I certainly haven't done that ever. The way I vision people are using serial port is to talk directly to it doing most if not all of the protocol handling with custom code, not with a library. If pass it (the input stream) to a library that chokes on read returning 0 it is rather your fault for not reading what the javadoc for SerialPort.getInputStream says! cheers Kusti From Kustaa.Nyholm at planmeca.com Thu May 21 01:49:36 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 21 May 2009 10:49:36 +0300 Subject: [Rxtx] InputStream timeouts - opinions on breaking compatibility? Message-ID: <5D23E5B41156B646B2E1A7C2BBA916F317119151B6@SRVFIHKIEXB01.pmgroup.local> Hi, changed the subject line a bit because I suspect most people have tuned out of this discussion and yet I feel that it is the very people who's input is needed. A month or so ago a lot of people chimed in by telling *what* they do with rxtx, now I would really be interesting to know *how* people are using rxtx? More specifically and relevant to this discussion: 1) are timeouts used? 2) how are they handled? 3) are SerialPort InputStreams passed to library functions? 4) have there been problems (in 3 above)? 5) how would you feel if you would need to rework your code to work with the 'improved' API? The proposal we have (by Gili) is: > 1) add "CommPortChannel getChannel()" This I do not mind so much as I do not need to touch my code. > 2) deprecate getInputStream() and enableReceiveTimeout() in favor of > getChannel() This I object to very much. One of my coding 'rules' say do-not-use-deprecated methods. An other rule says that my compiles-should-be-clean, so this would need me to change my code. Also, this is imposing and force feeding things to people who can't appreciate the beauty of the 'improvements' and are against them. > 3) getChannel() will return a class that implements the same interfaces as > SocketChannel. It will allow both blocking and non-blocking I/O operations. As I will not be using that (getChannel()) I don't care so much, but I bet this will be a new can worms having just the same sort of issues and compromises as we have been discussing here. But it would really be educational and fun to see proposers eat their own dog meat, so yes, let's do this! > 4) In RXTX 3.0 getInputStream() will return an InputStream that always blocks > on reads and the method will be undeprecated. > Just great, this is the top, I'm totally against this. Not only did (2) above require me to rework my code but now in phase two I would need to rework my code again to comply with yet another API change. There has to be better things in life and coding than tracking ever changing APIs! I'm involved in several projects ranging from a few thousand lines to several thousand hand written classes. Javacomm and rxtx play a small but crucial part in these. I would very much like to spend time on improving the applications instead of tracking changes in different APIs (not limited to rxtx). Especially changes that IMO only bring internal beauty . Our current code works and has been debugged to with the current API design, no compelling reason has been put forward to change the API and throw away the (albeit not so big) investment in learning to use the current API and making our code to work with it. All I care is that I have a cross platform serial port API that is stable and works as advertised, and which I do not have to implement and test on all the platforms. So far rxtx has been just wonderful, let's keep it that way. my 2 snt worth, cheers Kusti From michaeltandy at googlemail.com Thu May 21 05:48:44 2009 From: michaeltandy at googlemail.com (Michael Tandy) Date: Thu, 21 May 2009 12:48:44 +0100 Subject: [Rxtx] Buffer overflow caused by fhs_lock error message Message-ID: <302aa0340905210448v46b7ee61j58787b10500411b@mail.gmail.com> When, on Linux, one attempts to open a device such as /dev/ttyUSB71 and the device is locked, Java crashes with this error message: *** buffer overflow detected ***: java terminated ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7ead6d8] /lib/tls/i686/cmov/libc.so.6[0xb7eab800] /lib/tls/i686/cmov/libc.so.6[0xb7eaaef8] /lib/tls/i686/cmov/libc.so.6(_IO_default_xsputn+0xc8)[0xb7e20a78] /lib/tls/i686/cmov/libc.so.6(_IO_vfprintf+0x6f3)[0xb7df30b3] /lib/tls/i686/cmov/libc.so.6(__vsprintf_chk+0xa4)[0xb7eaafa4] /lib/tls/i686/cmov/libc.so.6(__sprintf_chk+0x2d)[0xb7eaaeed] /home/michael/Documents/asdf/lib/librxtxSerial.so(fhs_lock+0x1c2)[0xb4b82cf2] /home/michael/Documents/asdf/lib/librxtxSerial.so(Java_gnu_io_RXTXCommDriver_testRead+0x80)[0xb4b838a0] This is caused because trying to sprintf the error message, the device name, the error description, the newline and then null terminate the string overflows the 80 characters allocated. The problem code seems to be: char message[80]; sprintf( message,"RXTX fhs_lock() Error: creating lock file: %s: %s\n", file, strerror(errno) ); A switch to the buffer-overflow-proof snprintf function fixes the problem by truncating the error message if it exceeds 79 characters: char message[80]; snprintf( message, 80, "RXTX fhs_lock() Error: creating lock file: %s: %s\n", file, strerror(errno) ); A patch is attached to apply this fix - although there might be other bugs of this class in rxtx; it might be worth applying this fix anywhere sprintf is currently used. Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: overflowpatch.diff Type: application/octet-stream Size: 1133 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090521/3a487d21/attachment-0001.obj From rxtx at qbang.org Thu May 21 09:48:47 2009 From: rxtx at qbang.org (VIAGRA ® Official Site) Date: Thu, 21 May 2009 09:48:47 -0600 Subject: [Rxtx] Dear rxtx@qbang.org SALE 77% 0FF on Pfizer ! Message-ID: <200905211548.n4LFmltZ029873@rxtx.qbang.org> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090521/c9af7fb9/attachment.html From Klaus.Kierer at Tiscover.com Thu May 21 10:02:52 2009 From: Klaus.Kierer at Tiscover.com (Kierer, Klaus) Date: Thu, 21 May 2009 18:02:52 +0200 Subject: [Rxtx] Abwesenheitsnotiz: URL Filtering: Re: Dear rxtx@qbang.org SALE 77% 0FF on Pfizer ! Message-ID: <65FE44E2CAED5742B96A161F3703A5390861B0F5@ibk-tis-mx-01.tiscover.corp> Vielen Dank f?r Ihre Nachricht. Ich bin leider bis Montag, 25 Mai au?er Haus und werde mich erst anschlie?end um Ihr Anliegen k?mmern k?nnen. In dringenden F?llen senden Sie daher bitte ein Email an alexander.sommer at tiscover.com. Danke. Mit freundlichen Gr??en Klaus Kierer www.tiscover.com Thank you for your message. I am currently not contactable until Monday, 25th of May and thus cannot respond to your message until then. If your enquiry is urgent, please contact alexander.sommer at tiscover.com. Thank you. Kind Regards Klaus Kierer www.tiscover.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090521/0d4f9c57/attachment.html From pixue_breaker at hotmail.com Fri May 22 02:35:41 2009 From: pixue_breaker at hotmail.com (=?iso-8859-1?Q?Samuel_Ovia=F1o_Su=E1rez?=) Date: Fri, 22 May 2009 08:35:41 +0000 Subject: [Rxtx] porting rxtx to avr32-linux Message-ID: Hi! I'm trying to port rxtx to avr32-linux. My objetive is executing a serial comm app with jamvm running on avr32-linux platform so i need the suitable librxtxSerial.so for this. I have started to work in that following the next steps: 1. input : ./autogen.sh --host=avr32-linux --target=avr32-linux output : You should update your `aclocal.m4' by running aclocal acinclude.m4:6193: the serial number must appear before any macro definition 2. I updated aclocal comment out line 6193 of acinlcude.m4 and then i typed 'aclocal' 3. input: ./configure --host=avr32-linux --target=avr32-linux output: the makefile with avr32-linux settings After, i tried to 'make install' but compilation process stopped with this error: /home/samuel/Escritorio/rxtx-2.1-7r2/./src/SerialImp.h:441: error: expected declaration specifiers or '...' before 'wchar_t' avr32-linux-gcc -I/home/samuel/Escritorio/rxtx-2.1-7r2 -Iavr32-unknown-linux-gnu -I. -I/usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/include -I/usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/include/./ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c /home/samuel/Escritorio/rxtx-2.1-7r2/./src/fuserImp.c -fPIC -DPIC -o /home/samuel/Escritorio/rxtx-2.1-7r2/avr32-unknown-linux-gnu/.libs/fuserImp.o libtool: link: `/home/samuel/Escritorio/rxtx-2.1-7r2/avr32-unknown-linux-gnu/SerialImp.lo' is not a valid libtool object make: *** [avr32-unknown-linux-gnu/librxtxSerial.la] Error 1 What's wrong? Thanks in advance, Pixueto _________________________________________________________________ ?Qu?tate unos clics! Ahora, Internet Explorer 8 tiene todo lo que te gusta de Windows Live ?Cons?guelo gratis! http://ie8.msn.com/microsoft/internet-explorer-8/es-es/ie8.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090522/87e7bc4d/attachment-0001.html From luis.moreira at ntlworld.com Sat May 2 00:39:04 2009 From: luis.moreira at ntlworld.com (luis.moreira at ntlworld.com) Date: Sat, 2 May 2009 7:39:04 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Hi Travis, The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. The issues I still have is the errors after that. Do you have any idea what can be causing this errors? _______________________________________________________________________________ conftest.c: In function 'main': conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) conftest.c:8: error: (Each undeclared identifier is reported only once conftest.c:8: error: for each function it appears in.) conftest.c:8: error: expected ')' before string constant conftest.c:8: warning: format not a string literal and no format arguments ./configure: line 21462: ./conftest: No such file or directory ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands ------------------------------------------------------------------------------- I don't know what happened to my previous post, it as not showed up in the list. Best Regards Luis From tjarvi at qbang.org Sat May 2 07:30:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 07:30:04 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> References: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Message-ID: On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > Hi Travis, > The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. > The issues I still have is the errors after that. Do you have any idea what can be causing this errors? > > _______________________________________________________________________________ > conftest.c: In function 'main': > conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) > conftest.c:8: error: (Each undeclared identifier is reported only once > conftest.c:8: error: for each function it appears in.) > conftest.c:8: error: expected ')' before string constant > conftest.c:8: warning: format not a string literal and no format arguments > ./configure: line 21462: ./conftest: No such file or directory > ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: config.h is unchanged > config.status: executing depfiles commands > ------------------------------------------------------------------------------- > > This was corrected in CVS. I think you can just do the following in the top directory: cvs login: (pw is mousy) cvs update That will get the current fixes. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sat May 2 16:14:50 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sat, 02 May 2009 23:14:50 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FCC5DA.6000700@ntlworld.com> Trent Jarvi wrote: > > > On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > >> Hi Travis, >> The problem with the Makefile is not a problem,When I run ./configure >> I make a new Makefile with the same data in it, hence what I just >> modified is removed. >> The issues I still have is the errors after that. Do you have any >> idea what can be causing this errors? >> >> _______________________________________________________________________________ >> >> conftest.c: In function 'main': >> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >> function) >> conftest.c:8: error: (Each undeclared identifier is reported only once >> conftest.c:8: error: for each function it appears in.) >> conftest.c:8: error: expected ')' before string constant >> conftest.c:8: warning: format not a string literal and no format >> arguments >> ./configure: line 21462: ./conftest: No such file or directory >> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >> expected >> configure: creating ./config.status >> config.status: creating Makefile >> config.status: creating config.h >> config.status: config.h is unchanged >> config.status: executing depfiles commands >> ------------------------------------------------------------------------------- >> >> >> > > This was corrected in CVS. I think you can just do the following in > the top directory: > > cvs login: (pw is mousy) > cvs update > > That will get the current fixes. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, apologies for the mix-up of your name. I managed to get further on by updating CVS, the configure command gets to the end without any errors, it still warns me that it is confused about where to find the jni_md.h but I just edited the Makefile and sorted that out. I then run make, with no parameters following the instructions on the Wiki, but that generated a few more errors: ----------------------------------------------------------------------------------------------------------------------- gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. -I/usr/lib/jvm/java-6-openjdk/include /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' undeclared (first use in this function) /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared identifier is reported only once /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each function it appears in.) libtool: link: `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 ----------------------------------------------------------------------------------------------------------------------- Another question I have is, in which folder will the .so files be placed after make finishes? thank you very much for your help. Best Regards Luis From tjarvi at qbang.org Sat May 2 19:27:08 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 19:27:08 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FCC5DA.6000700@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> Message-ID: On Sat, 2 May 2009, Luis Moreira wrote: > Trent Jarvi wrote: >> >> >> On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: >> >>> Hi Travis, >>> The problem with the Makefile is not a problem,When I run ./configure >>> I make a new Makefile with the same data in it, hence what I just >>> modified is removed. >>> The issues I still have is the errors after that. Do you have any >>> idea what can be causing this errors? >>> >>> _______________________________________________________________________________ >>> >>> conftest.c: In function 'main': >>> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >>> function) >>> conftest.c:8: error: (Each undeclared identifier is reported only once >>> conftest.c:8: error: for each function it appears in.) >>> conftest.c:8: error: expected ')' before string constant >>> conftest.c:8: warning: format not a string literal and no format >>> arguments >>> ./configure: line 21462: ./conftest: No such file or directory >>> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >>> expected >>> configure: creating ./config.status >>> config.status: creating Makefile >>> config.status: creating config.h >>> config.status: config.h is unchanged >>> config.status: executing depfiles commands >>> ------------------------------------------------------------------------------- >>> >>> >>> >> >> This was corrected in CVS. I think you can just do the following in >> the top directory: >> >> cvs login: (pw is mousy) >> cvs update >> >> That will get the current fixes. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > apologies for the mix-up of your name. > I managed to get further on by updating CVS, the configure command gets > to the end without any errors, it still warns me that it is confused > about where to find the jni_md.h but I just edited the Makefile and > sorted that out. > I then run make, with no parameters following the instructions on the > Wiki, but that generated a few more errors: > ----------------------------------------------------------------------------------------------------------------------- > > gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. > -I/usr/lib/jvm/java-6-openjdk/include > /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE > -D_BSD_SOURCE -D__need_timespec -c > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o > /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' > undeclared (first use in this function) > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared > identifier is reported only once > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each > function it appears in.) > libtool: link: > `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a > valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 > ----------------------------------------------------------------------------------------------------------------------- > > Another question I have is, in which folder will the .so files be placed > after make finishes? > > thank you very much for your help. > Ah when you do cvs update pass the -Pd option cvs update -Pd Also, when you run configure, use --disable-PRINTER to only build the serial support. It will make things easier. --disable-LOCKFILES will also be easier to get going until you want to learn about how to prevent multiple applications from reading the same serial port. The link for debugging will describe where the files go. By default, it will install in the JRE/JDK under jre/lib/ext (the jar file) jre/lib/i386 (the .so file) Those are on the proper paths when you use the sun or ibm jdk. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sun May 3 01:30:43 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sun, 03 May 2009 08:30:43 +0100 Subject: [Rxtx] First use of RXTX package In-Reply-To: References: <49FCC5DA.6000700@ntlworld.com> Message-ID: <49FD4823.5080204@ntlworld.com> Ah > > when you do cvs update pass the -Pd option > > cvs update -Pd > > Also, when you run configure, use --disable-PRINTER to only build the > serial support. It will make things easier. --disable-LOCKFILES will > also be easier to get going until you want to learn about how to > prevent multiple applications from reading the same serial port. > > The link for debugging will describe where the files go. By default, > it will install in the JRE/JDK under > > jre/lib/ext (the jar file) > jre/lib/i386 (the .so file) > > Those are on the proper paths when you use the sun or ibm jdk. > > http://rxtx.qbang.org/wiki/index.php/Trouble_shooting > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, It as done it! I think this instructions you gave me should be on the Wiki, I can write them for you if you like. Also on the Wiki when you describe the three methods of installing the RxTx package it is confusing because as far as I can see, you always have to do method 1 or the .so files will not be generated(is this correct?). Then you can if you like change the location with method 1 & 2. Is it possible to modify the .la file to point to different directories for installation and then you can decide where to place the files? In a way I have learned quite a lot about Linux by having to struggle, with your help, to find solutions to the problems I encountered (I am still very new to Linux), but maybe we need to log these problems somewhere to make it less of a struggle for others like me. I have used the PortLister example to test it and it came up with my USB to dual Serial adaptor Ports. I will now explore the RxTx package, before I tackle the windows installation, I will let you know of my experience. Thank you for all your Help. Best Regards Luis From tjarvi at qbang.org Sun May 3 10:37:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 3 May 2009 10:37:50 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FD4823.5080204@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> <49FD4823.5080204@ntlworld.com> Message-ID: On Sun, 3 May 2009, Luis Moreira wrote: > Ah >> >> when you do cvs update pass the -Pd option >> >> cvs update -Pd >> >> Also, when you run configure, use --disable-PRINTER to only build the >> serial support. It will make things easier. --disable-LOCKFILES will >> also be easier to get going until you want to learn about how to >> prevent multiple applications from reading the same serial port. >> >> The link for debugging will describe where the files go. By default, >> it will install in the JRE/JDK under >> >> jre/lib/ext (the jar file) >> jre/lib/i386 (the .so file) >> >> Those are on the proper paths when you use the sun or ibm jdk. >> >> http://rxtx.qbang.org/wiki/index.php/Trouble_shooting >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > It as done it! > I think this instructions you gave me should be on the Wiki, I can write > them for you if you like. Also on the Wiki when you describe the three > methods of installing the RxTx package it is confusing because as far > as I can see, you always have to do method 1 or the .so files will not > be generated(is this correct?). Then you can if you like change the > location with method 1 & 2. Is it possible to modify the .la file to > point to different directories for installation and then you can decide > where to place the files? > In a way I have learned quite a lot about Linux by having to struggle, > with your help, to find solutions to the problems I encountered (I am > still very new to Linux), but maybe we need to log these problems > somewhere to make it less of a struggle for others like me. > > I have used the PortLister example to test it and it came up with my USB > to dual Serial adaptor Ports. > > I will now explore the RxTx package, before I tackle the windows > installation, I will let you know of my experience. > > Thank you for all your Help. > Hi Luis, The locations suggested for first time configuration could be documented in a new wiki page explaining that this is not the recommended general workflow but does help new users that are not worried about having rxtx installed into the JRE. For a professional environment, the user would want to follow the workflow currently on the wiki and keep their JRE clean. Often the user will not be able to add libraries to the JRE and will need to use their home directory or a sandbox. Feel free to add information to the wiki. I'd suggest creating comment in the current page and have the comment link to what worked for you as a first time user new to Linux. You can create a new page with your comments. In the long term, we will be working on an autoinstaller that works over the web. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Mon May 4 09:15:40 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Mon, 04 May 2009 16:15:40 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FF069C.8040406@ntlworld.com> Hi Trent, I have now installed the package on my 64 bit machine and when I run my program I get errors on the attachment. I know it as something to do with the architecture of my system but I can no figure out how to fix it. I have built it from source again, I did not transfer the files from machine to machine. can you please put me in the right direction. Thank you very much for your help. Best Regards Luis -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshoot.png Type: image/png Size: 25753 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090504/141ab5dc/attachment-0019.png From johnny.luong at trustcommerce.com Mon May 4 11:57:08 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 04 May 2009 10:57:08 -0700 Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FF069C.8040406@ntlworld.com> References: <49FF069C.8040406@ntlworld.com> Message-ID: <49FF2C74.90805@trustcommerce.com> Luis Moreira wrote: > Hi Trent, > I have now installed the package on my 64 bit machine and when I run my > program I get errors on the attachment. I know it as something to do > with the architecture of my system but I can no figure out how to fix > it. I have built it from source again, I did not transfer the files from > machine to machine. > can you please put me in the right direction. > Thank you very much for your help. > Best Regards > Luis > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Hi, Does running it on a 64-bit JVM help? Your host environment might be building objects for a 64-bit environment unless you did a cross-compile... -- you can find out by doing something like the following: johnny at spike:~$ java -version java version "1.6.0_0" OpenJDK Runtime Environment (build 1.6.0_0-b11) OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode) johnny at spike:~$ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) -Johnny From huangdongkai at gmail.com Wed May 6 11:06:06 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 01:06:06 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. Message-ID: Dear all, I recompile the rxtxSerial source code by MinGW32 and compile success. But when I run my Application which use rxtxSerial.dll to communicate with serial port, a runtime exception happened and application crash. I have no idea why it can not work, beacuse i have not change any source code of rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I have missed when compile the source code on Window NT? Here below is the output error massage. # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, tid=1360 # # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing windows-x86) # Problematic frame: # V [jvm.dll+0x1b6824] # # An error report file with more information is saved as: # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/32c1e699/attachment-0017.html From tjarvi at qbang.org Wed May 6 20:04:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 May 2009 20:04:10 -0600 (MDT) Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: On Thu, 7 May 2009, dongkai huang wrote: > Dear all, > ????? I recompile the rxtxSerial source code by MinGW32 and compile success. > But when I run my Application which use rxtxSerial.dll to communicate with > serial port, a runtime exception happened and application crash.? I have no > idea why it can not work, beacuse i have not change any source code of > rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I > have missed when compile the source code on Window NT? Here below is the > output error massage. > # > # An unexpected error has been detected by Java Runtime Environment: > # > #? EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, > tid=1360 > # > # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing > windows-x86) > > # Problematic frame: > # V? [jvm.dll+0x1b6824] > # > # An error report file with more information is saved as: > # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log > # > # If you would like to submit a bug report, please visit: > #?? http://java.sun.com/webapps/bugreport/crash.jsp > # > > > Hi Dongkai Could you explain how you compiled rxtx with mingw? Did you run configure? Was the compiler native or a cross compiler (like compiling on Linux for Windows)? Is the crash happening when you first open the port or is it happening randomly later on? -- Trent Jarvi tjarvi at qbang.org From huangdongkai at gmail.com Wed May 6 20:48:56 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 10:48:56 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Hi Trent, I was followed the step on INSTALL file, did not run the configure, I used the Makefile.mingw32 which include on the source code package, and only change some path( jdk home path etc.). And I use the native compiler on Windows. The crash happened on I call the getPortIdentifiers() every time. On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Dear all, >> I recompile the rxtxSerial source code by MinGW32 and compile >> success. >> But when I run my Application which use rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and application crash. I have >> no >> idea why it can not work, beacuse i have not change any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing >> I >> have missed when compile the source code on Window NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is saved as: >> # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> > Hi Dongkai > > Could you explain how you compiled rxtx with mingw? Did you run configure? > Was the compiler native or a cross compiler (like compiling on Linux for > Windows)? > > Is the crash happening when you first open the port or is it happening > randomly later on? > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/733eded5/attachment-0017.html From m.j.tandy at warwick.ac.uk Thu May 7 10:39:12 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 7 May 2009 17:39:12 +0100 Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. Message-ID: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> I've encountered a bug in how XON/XOFF are handled on Windows. The symptoms were: 1. XON/XOFF from device to PC did not stop transmission. 2. XON/XOFF characters were present in data read from serial port input stream, when it was expected that they would be stripped out. 3. Investigation with SysInternals PortMon revealed the following configuration when using rxtx: 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 while HyperTerminal, which did not have the same problems as me, produced the following: 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 In other words, the problem is that, in addition to being told to use XON/XOFF flow control, the computer has to explicitly be told which characters to use for 'XON' and 'XOFF'. This part of the configuration was being missed out. I got the latest rxtx source from CVS, and identified the problem as an omission in the 'init_termios' function of 'termios.c', which configures the unix/termios 'c_cc' (control characters) data structure - but omits to configure the VSTART and VSTOP control characters. Later, the termios c_cc data structure is translated (by termios_to_DCB) into a data structure named 'DCB', which is passed to the windows serial port configuration interface. By adding two lines defining the standard XON/XOFF characters to the function init_termios, the bug is fixed. A patch doing this is attached. Thanks, Michael Tandy -------------- next part -------------- A non-text attachment was scrubbed... Name: xon-xoff.diff Type: application/octet-stream Size: 667 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/159c0dcc/attachment-0016.obj From tjarvi at qbang.org Thu May 7 17:57:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 May 2009 17:57:28 -0600 (MDT) Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. In-Reply-To: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> References: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> Message-ID: On Thu, 7 May 2009, Michael Tandy wrote: > I've encountered a bug in how XON/XOFF are handled on Windows. > > The symptoms were: > 1. XON/XOFF from device to PC did not stop transmission. > 2. XON/XOFF characters were present in data read from serial port > input stream, when it was expected that they would be stripped out. > 3. Investigation with SysInternals PortMon revealed the following > configuration when using rxtx: > > 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 > BRK:0 EVT:a XON:0 XOFF:0 > > while HyperTerminal, which did not have the same problems as me, > produced the following: > > 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 > > In other words, the problem is that, in addition to being told to use > XON/XOFF flow control, the computer has to explicitly be told which > characters to use for 'XON' and 'XOFF'. This part of the configuration > was being missed out. > > I got the latest rxtx source from CVS, and identified the problem as > an omission in the 'init_termios' function of 'termios.c', which > configures the unix/termios 'c_cc' (control characters) data structure > - but omits to configure the VSTART and VSTOP control characters. > Later, the termios c_cc data structure is translated (by > termios_to_DCB) into a data structure named 'DCB', which is passed to > the windows serial port configuration interface. > > By adding two lines defining the standard XON/XOFF characters to the > function init_termios, the bug is fixed. A patch doing this is > attached. > Thanks Michael, Good timing. I plan on releasing rxtx-2.2 this coming Sunday. -- Trent Jarvi tjarvi at qbang.org From wjr at weru.ksu.edu Fri May 8 11:38:29 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Fri, 08 May 2009 12:38:29 -0500 Subject: [Rxtx] swing jfilechooser lockup Message-ID: <4A046E15.6010907@weru.ksu.edu> Hi, I wrote a small swing app to download images from an industrial camera. I used the two way serial sample code as a starting point. The app works fine EXCEPT for a call to jfilechooser. After I open the comm port and then try to change the output directory or log file, the jfilechooser winds up trying to unpark (note, parking is not something I'm really familiar with) and doesn't. If I try to change the file or directory before I start the comm port, it works. If I click on menu items that don't call jfilechooser, everything is OK. If I try closing the comm port and then try to create a jfilechooser, it locks up. There is obviously some sort of deadlock here because the awt thread starts waiting on something but it's not clear what. I haven't gone thru the rxtx code yet because it's not in the file structure that netbeans wants for debugging purposes. However, debugging code that I don't have a clear idea of what it is supposed to do is not my idea of a good time. Does anyone have any ideas on what is going on here? Thanks, wjr From Bob_Jacobsen at lbl.gov Fri May 8 14:48:25 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Fri, 8 May 2009 13:48:25 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A046E15.6010907@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> Message-ID: At 12:38 PM -0500 5/8/09, Bill Rust wrote: >Hi, > >I wrote a small swing app to download images from an industrial camera. >I used the two way serial sample code as a starting point. The app works >fine EXCEPT for a call to jfilechooser. After I open the comm port and >then try to change the output directory or log file, the jfilechooser >winds up trying to unpark (note, parking is not something I'm really >familiar with) and doesn't. If I try to change the file or directory >before I start the comm port, it works. If I click on menu items that >don't call jfilechooser, everything is OK. If I try closing the comm >port and then try to create a jfilechooser, it locks up. There is >obviously some sort of deadlock here because the awt thread starts >waiting on something but it's not clear what. I haven't gone thru the >rxtx code yet because it's not in the file structure that netbeans wants >for debugging purposes. However, debugging code that I don't have a >clear idea of what it is supposed to do is not my idea of a good time. What is the threading structure of your code? The various high-function Swing components, such as JFileChooser, are notorious for doing Really Bad Stuff when invoked from off the Swing thread. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From bschlining at gmail.com Fri May 8 15:08:50 2009 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 8 May 2009 14:08:50 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: Bob's probably right...take look at javax.swing.SwingUtilites for the workaround to get your swing stuff invoked on the EventDispatchThread (EDT). Some swing-methods do work when called outside of the EDT, but just to be safe, do your creation and swing calls on the EDT. It's really simple, here's an example of a synchronous call. // Here's how to run stuff on the EDT from a different thread SwingUtilities.invokeAndWait(new Runnable() { public void run() { JFileChooser fc; // create, setup, show your filechooser // Get the result from the filechooser } }); To do a asynchronous call use SwingUtilities.invokeLater > >I wrote a small swing app to download images from an industrial camera. > >I used the two way serial sample code as a starting point. The app works > >fine EXCEPT for a call to jfilechooser. After I open the comm port and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090508/c21c2127/attachment-0015.html From tod at todbot.com Fri May 8 16:27:12 2009 From: tod at todbot.com (Tod E. Kurt) Date: Fri, 8 May 2009 15:27:12 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> This is the exact technique I use to let the user choose which serial port to use on startup. Here's a method I've got in many of my sketches: void choosePort() { String portlist[] = Serial.list(); String port = null; javax.swing.SwingUtilities.invokeLater(new Runnable() { public void run() { try { String port = (String) javax.swing.JOptionPane.showInputDialog( null, "Select Serial Port", "MySuperSketch", javax.swing.JOptionPane.QUESTION_MESSAGE, null, portlist, null); if( port == null ) { javax.swing.JOptionPane.showMessageDialog(null, "No port chosen, goodbye"); System.exit(1); } serialPort = port; } catch (Exception e) { e.printStackTrace(); } } } ); } On May 8, 2009, at 2:08 p, Brian Schlining wrote: > Bob's probably right...take look at javax.swing.SwingUtilites for > the workaround to get your swing stuff invoked on the > EventDispatchThread (EDT). Some swing-methods do work when called > outside of the EDT, but just to be safe, do your creation and swing > calls on the EDT. It's really simple, here's an example of a > synchronous call. > > // Here's how to run stuff on the EDT from a different thread > SwingUtilities.invokeAndWait(new Runnable() { > public void run() { > JFileChooser fc; // create, setup, show your filechooser > // Get the result from the filechooser > } > }); > > To do a asynchronous call use SwingUtilities.invokeLater > > > >I wrote a small swing app to download images from an industrial > camera. > >I used the two way serial sample code as a starting point. The app > works > >fine EXCEPT for a call to jfilechooser. After I open the comm port > and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From huangdongkai at gmail.com Sat May 9 04:46:22 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Sat, 9 May 2009 18:46:22 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Dear Trent, After I intsall the ming32-cross compile to compile the rxtxSerial.dll and testing, i found the same problem still exist. I am not sure my compiler version is the same as your's. Could you tell me the way you can success compile rxtx-2.1-7r2 release source code? Thanks for you kindly help. On Fri, May 8, 2009 at 8:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Hi Trent, >> The attach is the Make file I use to compile the rxtx. >> >> On Thu, May 7, 2009 at 10:48 AM, dongkai huang >> wrote: >> Hi Trent, >> I was followed the step on INSTALL file, did not run the >> configure, I used the Makefile.mingw32 which include on the >> source code package, and only change some path( jdk home path >> etc.). And I use the native compiler on Windows. >> The crash happened on I call the getPortIdentifiers() >> every time. >> >> On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: >> >> >> On Thu, 7 May 2009, dongkai huang wrote: >> >> Dear all, >> I recompile the rxtxSerial source code by >> MinGW32 and compile success. >> But when I run my Application which use >> rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and >> application crash. I have no >> idea why it can not work, beacuse i have not change >> any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source >> code. Did some thing I >> have missed when compile the source code on Window >> NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java >> Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at >> pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 >> mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is >> saved as: >> # >> D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please >> visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> >> Hi Dongkai >> >> Could you explain how you compiled rxtx with mingw? Did you run >> configure? Was the compiler native or a cross compiler (like >> compiling on Linux for Windows)? >> >> Is the crash happening when you first open the port or is it >> happening randomly later on? >> >> > Thanks Dongkai > > I'll look at your Makefile tomorrow. Which version of mingw was this? > > I suspect there is a problem with that makefile. I usually built that > version of rxtx for windows with a mingw32 cross compiler using the > configure script. > > The configure script may well work for you if you have a cygwin environment > with mingw instead of gcc. I'll take a look at what is different. > > -- > > Trent Jarvi > tjarvi at qbang.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090509/b729c429/attachment-0015.html From wjr at weru.ksu.edu Wed May 13 15:50:30 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Wed, 13 May 2009 16:50:30 -0500 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> Message-ID: <4A0B40A6.5070204@weru.ksu.edu> Tod's solution misses the point. He is picking and opening the serial port. That's the step before where my problem occurs. To recap: 1. I have a simple java swing app. 2. On the menu bar, there is the standard set, file, etc., of jmenu's. Under file, there is a jmenuitem, logfileopen, which pops up a jfilechooser to select a logfile and another jmenuitem, setprefix, which pops up a jdialog to allow the user to type in a file name prefix for downloaded images. 3. There is another jmenuitem that starts the commport running. 4. When logfileopen is pressed before the commport is started, it works. 5. When logfileopen is pressed after the commport is started, it hangs. 6. setprefix works whether or not the commport is started. 7. portIdentifier.open starts a thread that goes into a native method, RXTXPort.eventLoop, and never returns. 8. java.sun bugs has a bug report, 6741890, that is similar but their workaround doesn't. 9. When it locks up, there is a swing-shell thread that appears to be down in some native libraries, winshellfolder2 10. The awt-eventQ thread is unblocked but in code that says its parked. If you have anymore ideas, I'd really appreciate them. wjr Tod E. Kurt wrote: > This is the exact technique I use to let the user choose which serial > port to use on startup. Here's a method I've got in many of my sketches: > > void choosePort() { > String portlist[] = Serial.list(); > String port = null; > javax.swing.SwingUtilities.invokeLater(new Runnable() { > public void run() { > try { > String port = (String) javax.swing.JOptionPane.showInputDialog( > null, > "Select Serial Port", > "MySuperSketch", > javax.swing.JOptionPane.QUESTION_MESSAGE, > null, portlist, null); > if( port == null ) { > javax.swing.JOptionPane.showMessageDialog(null, "No port > chosen, goodbye"); > System.exit(1); > } > serialPort = port; > } > catch (Exception e) { > e.printStackTrace(); > } > } > } ); > } > > > On May 8, 2009, at 2:08 p, Brian Schlining wrote: > >> Bob's probably right...take look at javax.swing.SwingUtilites for the >> workaround to get your swing stuff invoked on the EventDispatchThread >> (EDT). Some swing-methods do work when called outside of the EDT, but >> just to be safe, do your creation and swing calls on the EDT. It's >> really simple, here's an example of a synchronous call. >> >> // Here's how to run stuff on the EDT from a different thread >> SwingUtilities.invokeAndWait(new Runnable() { >> public void run() { >> JFileChooser fc; // create, setup, show your filechooser >> // Get the result from the filechooser >> } >> }); >> >> To do a asynchronous call use SwingUtilities.invokeLater >> >> >> >I wrote a small swing app to download images from an industrial camera. >> >I used the two way serial sample code as a starting point. The app works >> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >> >then try to change the output directory or log file, the jfilechooser >> >winds up trying to unpark (note, parking is not something I'm really >> >familiar with) and doesn't. >> What is the threading structure of your code? >> >> The various high-function Swing components, such as JFileChooser, are >> notorious for doing Really Bad Stuff when invoked from off the Swing >> thread. >> >> Bob >> -- >> Bob Jacobsen, UC Berkeley >> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >> JacobsenRG >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -- >> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >> Brian Schlining >> bschlining at gmail.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx From m.j.tandy at warwick.ac.uk Wed May 13 16:42:24 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 13 May 2009 23:42:24 +0100 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A0B40A6.5070204@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> <4A0B40A6.5070204@weru.ksu.edu> Message-ID: <302aa0340905131542i601ec3f1w3b0b5879c23f8eca@mail.gmail.com> Perhaps you could post your program, or an excerpt of it sufficient to demonstrate the problem you're having, for us to have a look at? 2009/5/13 Bill Rust : > Tod's solution misses the point. He is picking and opening the serial > port. That's the step before where my problem occurs. > > To recap: > > 1. I have a simple java swing app. > 2. On the menu bar, there is the standard set, file, etc., of jmenu's. > Under file, there is a jmenuitem, logfileopen, which pops up a > jfilechooser to select a logfile and another jmenuitem, setprefix, which > pops up a jdialog to allow the user to type in a file name prefix for > downloaded images. > 3. There is another jmenuitem that starts the commport running. > 4. When logfileopen is pressed before the commport is started, it works. > 5. When logfileopen is pressed after the commport is started, it hangs. > 6. setprefix works whether or not the commport is started. > 7. portIdentifier.open starts a thread that goes into a native > method, ? ? ? ? ? ? ? ? ? ? ? ? RXTXPort.eventLoop, and never returns. > 8. java.sun bugs has a bug report, 6741890, that is similar but > their ? ? ? ? ? ? ? ? ? workaround doesn't. > 9. When it locks up, there is a swing-shell thread that appears to be > ? ? ? ?down in some native libraries, winshellfolder2 > 10. The awt-eventQ thread is unblocked but in code that says its parked. > > If you have anymore ideas, I'd really appreciate them. > > wjr > > Tod E. Kurt wrote: >> This is the exact technique I use to let the user choose which serial >> port to use on startup. ?Here's a method I've got in many of my sketches: >> >> void choosePort() { >> ? String portlist[] = Serial.list(); >> ? String port = null; >> ? javax.swing.SwingUtilities.invokeLater(new Runnable() { >> ? ? public void run() { >> ? ? ? try { >> ? ? ? ? String port = (String) javax.swing.JOptionPane.showInputDialog( >> null, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Select Serial Port", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "MySuperSketch", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? javax.swing.JOptionPane.QUESTION_MESSAGE, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? null, portlist, null); >> ? ? ? ? if( port == null ) ?{ >> ? ? ? ? ? javax.swing.JOptionPane.showMessageDialog(null, "No port >> chosen, goodbye"); >> ? ? ? ? ? System.exit(1); >> ? ? ? ? } >> ? ? ? ? serialPort = port; >> ? ? ? } >> ? ? ? catch (Exception e) { >> ? ? ? ? e.printStackTrace(); >> ? ? ? } >> ? ? } >> ? } ); >> } >> >> >> On May 8, 2009, at 2:08 p, Brian Schlining wrote: >> >>> Bob's probably right...take look at javax.swing.SwingUtilites for the >>> workaround to get your swing stuff invoked on the EventDispatchThread >>> (EDT). Some swing-methods do work when called outside of the EDT, but >>> just to be safe, do your creation and swing calls on the EDT. It's >>> really simple, here's an example of a synchronous call. >>> >>> // Here's how to run stuff on the EDT from a different thread >>> SwingUtilities.invokeAndWait(new Runnable() { >>> ? ? ? public void run() { >>> ? ? ? ? ? ?JFileChooser fc; // create, setup, show your filechooser >>> ? ? ? ? ? ?// Get the result from the filechooser >>> ? ? ? } >>> }); >>> >>> To do a asynchronous call use SwingUtilities.invokeLater >>> >>> >>> >I wrote a small swing app to download images from an industrial camera. >>> >I used the two way serial sample code as a starting point. The app works >>> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >>> >then try to change the output directory or log file, the jfilechooser >>> >winds up trying to unpark (note, parking is not something I'm really >>> >familiar with) and doesn't. >>> What is the threading structure of your code? >>> >>> The various high-function Swing components, such as JFileChooser, are >>> notorious for doing Really Bad Stuff when invoked from off the Swing >>> thread. >>> >>> Bob >>> -- >>> Bob Jacobsen, UC Berkeley >>> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >>> JacobsenRG >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >>> -- >>> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >>> Brian Schlining >>> bschlining at gmail.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From m.j.tandy at warwick.ac.uk Thu May 14 03:05:36 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 14 May 2009 10:05:36 +0100 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A0B40A6.5070204@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> <4A0B40A6.5070204@weru.ksu.edu> Message-ID: <302aa0340905140205p6ceb5a9br24e00a50e9cafa5@mail.gmail.com> Java has a built in deadlock detection utility; run your program from the command line, then (on windows) press Ctrl+Break (On Linux, Ctrl+\ does the trick I'm told). That should produce status information and a stack trace for every running thread, including locks held and locks waited on. Maybe that would contain enough information for you to work out what's locking what? 2009/5/13 Bill Rust : > Tod's solution misses the point. He is picking and opening the serial > port. That's the step before where my problem occurs. > > To recap: > > 1. I have a simple java swing app. > 2. On the menu bar, there is the standard set, file, etc., of jmenu's. > Under file, there is a jmenuitem, logfileopen, which pops up a > jfilechooser to select a logfile and another jmenuitem, setprefix, which > pops up a jdialog to allow the user to type in a file name prefix for > downloaded images. > 3. There is another jmenuitem that starts the commport running. > 4. When logfileopen is pressed before the commport is started, it works. > 5. When logfileopen is pressed after the commport is started, it hangs. > 6. setprefix works whether or not the commport is started. > 7. portIdentifier.open starts a thread that goes into a native > method, ? ? ? ? ? ? ? ? ? ? ? ? RXTXPort.eventLoop, and never returns. > 8. java.sun bugs has a bug report, 6741890, that is similar but > their ? ? ? ? ? ? ? ? ? workaround doesn't. > 9. When it locks up, there is a swing-shell thread that appears to be > ? ? ? ?down in some native libraries, winshellfolder2 > 10. The awt-eventQ thread is unblocked but in code that says its parked. > > If you have anymore ideas, I'd really appreciate them. > > wjr > > Tod E. Kurt wrote: >> This is the exact technique I use to let the user choose which serial >> port to use on startup. ?Here's a method I've got in many of my sketches: >> >> void choosePort() { >> ? String portlist[] = Serial.list(); >> ? String port = null; >> ? javax.swing.SwingUtilities.invokeLater(new Runnable() { >> ? ? public void run() { >> ? ? ? try { >> ? ? ? ? String port = (String) javax.swing.JOptionPane.showInputDialog( >> null, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Select Serial Port", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "MySuperSketch", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? javax.swing.JOptionPane.QUESTION_MESSAGE, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? null, portlist, null); >> ? ? ? ? if( port == null ) ?{ >> ? ? ? ? ? javax.swing.JOptionPane.showMessageDialog(null, "No port >> chosen, goodbye"); >> ? ? ? ? ? System.exit(1); >> ? ? ? ? } >> ? ? ? ? serialPort = port; >> ? ? ? } >> ? ? ? catch (Exception e) { >> ? ? ? ? e.printStackTrace(); >> ? ? ? } >> ? ? } >> ? } ); >> } >> >> >> On May 8, 2009, at 2:08 p, Brian Schlining wrote: >> >>> Bob's probably right...take look at javax.swing.SwingUtilites for the >>> workaround to get your swing stuff invoked on the EventDispatchThread >>> (EDT). Some swing-methods do work when called outside of the EDT, but >>> just to be safe, do your creation and swing calls on the EDT. It's >>> really simple, here's an example of a synchronous call. >>> >>> // Here's how to run stuff on the EDT from a different thread >>> SwingUtilities.invokeAndWait(new Runnable() { >>> ? ? ? public void run() { >>> ? ? ? ? ? ?JFileChooser fc; // create, setup, show your filechooser >>> ? ? ? ? ? ?// Get the result from the filechooser >>> ? ? ? } >>> }); >>> >>> To do a asynchronous call use SwingUtilities.invokeLater >>> >>> >>> >I wrote a small swing app to download images from an industrial camera. >>> >I used the two way serial sample code as a starting point. The app works >>> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >>> >then try to change the output directory or log file, the jfilechooser >>> >winds up trying to unpark (note, parking is not something I'm really >>> >familiar with) and doesn't. >>> What is the threading structure of your code? >>> >>> The various high-function Swing components, such as JFileChooser, are >>> notorious for doing Really Bad Stuff when invoked from off the Swing >>> thread. >>> >>> Bob >>> -- >>> Bob Jacobsen, UC Berkeley >>> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >>> JacobsenRG >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >>> -- >>> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >>> Brian Schlining >>> bschlining at gmail.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From cowwoc at bbs.darktech.org Fri May 15 07:18:29 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 09:18:29 -0400 Subject: [Rxtx] InputStream timeouts Message-ID: <4A0D6BA5.8020209@bbs.darktech.org> Why does InputStream.read() return -1 on timeout instead of throwing InterruptedIOException which has existed specifically for this purpose since JDK 1.0? Sockets throw SocketTimeoutException which extends InterruptedIOException. I suspect that this logic confuses BufferedInputStream as well as end-users. Can we introduce this change along with the other timeout-related changes? Gili From Steffen.DETTMER at ingenico.com Fri May 15 07:36:19 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 15 May 2009 15:36:19 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0D6BA5.8020209@bbs.darktech.org> References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <20090515133619.GC17036@elberon.bln.de.ingenico.com> * cowwoc wrote on Fri, May 15, 2009 at 09:18 -0400: > Why does InputStream.read() return -1 on timeout shouldn't it block and only avialable() should care about timeouts? That is how I understand `This method blocks until input data is available' from: http://java.sun.com/j2se/1.5.0/docs/api/java/io/InputStream.html#read() public abstract int read() throws IOException Reads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. A subclass must provide an implementation of this method. Returns: the next byte of data, or -1 if the end of the stream is reached. Throws: IOException - if an I/O error occurs. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Fri May 15 08:22:19 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 15 May 2009 17:22:19 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: >From the javadoc for InputStream: "If no byte is available because the end of the stream has been reached, the value -1 is returned." Since character timeout is not an indication of EOF condition I guess one could argue that 0 should be returned in case of timeout. On the other hand one could also argue that since no data was available (if it timed out) the serial port input stream was at the end of stream (albeit possibly temporarily only). Further the javadoc seems to forbid the return value 0 for Inputstream.read(): " This method blocks until input data is available, the end of the stream is detected, or an exception is thrown." So it can return n >= 1 , -1 or throw an exception. InputStream.read(byte[]) can return 0 but for consistency the options with the other read methods the return value for timeout needs to be -1 or an exception. It goes against my grain to think that I get an exception when I've set up a timeout and I am thus expecting a timeout to happen sometimes. So it is not an exceptional case but expected situation in which case a special return value is philosophically speaking more appropriate. So I'm against changing this behavior. I expect a lot of code depend on the -1 or at least on not getting an exception when a timeout occurs. In any case if an exception were to be thrown it should *not* be InterruptedIOException. >From the javadoc for InterruptedIOException: "An InterruptedIOException is thrown to indicate that an input or output transfer has been terminated because the thread performing it was interrupted. The field bytesTransferred indicates how many bytes were successfully transferred before the interruption occurred" I do not think this matches the case for serial port receive character timeout. I read the javadoc above so that I get this exception when the thread in my code that is performing a read or write operation gets interrupted by Thread.interrupt(). And this is used to handle exactly that case: being able to gracefully and cleanly interrupt threads. my 2 snt worth br Kusti > From: cowwoc > Date: Fri, 15 May 2009 16:18:29 +0300 > To: rxtx > Conversation: [Rxtx] InputStream timeouts > Subject: [Rxtx] InputStream timeouts > > > > Why does InputStream.read() return -1 on timeout instead of > throwing InterruptedIOException which has existed specifically for this > purpose since JDK 1.0? Sockets throw SocketTimeoutException which > extends InterruptedIOException. I suspect that this logic confuses > BufferedInputStream as well as end-users. Can we introduce this change > along with the other timeout-related changes? > > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From cowwoc at bbs.darktech.org Fri May 15 08:35:27 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 10:35:27 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <4A0D7DAF.5030705@bbs.darktech.org> I disagree with your interpretation. Read SocketTimeoutException to see what I mean. InterruptedIOException means the operation was interrupted, not necessarily by way of Thread.interrupt(). Returning 0 in case of timeout sounds wrong to me because it is a legal byte value that could have been read. Returning -1 also sounds wrong to me because this isn't strictly the end of stream. BufferedInputStream and others assume that once you reach the end of stream you will never see more data, ever. As far as I know, the core APIs are written in terms of throwing InterruptedIOException for timeouts. Gili Kustaa Nyholm wrote: > >>From the javadoc for InputStream: > > "If no byte is available because the end of the stream has been reached, the > value -1 is returned." > > > Since character timeout is not an indication of EOF condition I guess one > could argue that 0 should be returned in case of timeout. On the other hand > one could also argue that since no data was available (if it timed out) the > serial port input stream was at the end of stream (albeit possibly > temporarily only). Further the javadoc seems to forbid the return value 0 > for Inputstream.read(): > > " This method blocks until input data is available, the end of the stream is > detected, or an exception is thrown." > > So it can return n >= 1 , -1 or throw an exception. InputStream.read(byte[]) > can return 0 but for consistency the options with the other read methods the > return value for timeout needs to be -1 or an exception. > > It goes against my grain to think that I get an exception when I've set up a > timeout and I am thus expecting a timeout to happen sometimes. So it is not > an exceptional case but expected situation in which case a special return > value is philosophically speaking more appropriate. > > So I'm against changing this behavior. I expect a lot of code depend on the > -1 or at least on not getting an exception when a timeout occurs. > > In any case if an exception were to be thrown it should *not* be > InterruptedIOException. > >>From the javadoc for InterruptedIOException: > > > "An InterruptedIOException is thrown to indicate that an input or output > transfer has been terminated because the thread performing it was > interrupted. The field bytesTransferred indicates how many bytes were > successfully transferred before the interruption occurred" > > I do not think this matches the case for serial port receive character > timeout. I read the javadoc above so that I get this exception when the > thread in my code that is performing a read or write operation gets > interrupted by Thread.interrupt(). And this is used to handle exactly that > case: being able to gracefully and cleanly interrupt threads. > > > > my 2 snt worth br Kusti > > > > >> From: cowwoc >> Date: Fri, 15 May 2009 16:18:29 +0300 >> To: rxtx >> Conversation: [Rxtx] InputStream timeouts >> Subject: [Rxtx] InputStream timeouts >> >> >> >> Why does InputStream.read() return -1 on timeout instead of >> throwing InterruptedIOException which has existed specifically for this >> purpose since JDK 1.0? Sockets throw SocketTimeoutException which >> extends InterruptedIOException. I suspect that this logic confuses >> BufferedInputStream as well as end-users. Can we introduce this change >> along with the other timeout-related changes? >> >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From m.j.tandy at warwick.ac.uk Fri May 15 09:17:36 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Fri, 15 May 2009 16:17:36 +0100 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <302aa0340905150817o39812d7y1b896004a2dcc2ab@mail.gmail.com> > I disagree with your interpretation. Read SocketTimeoutException to see > what I mean. InterruptedIOException means the operation was interrupted, > not necessarily by way of Thread.interrupt(). Strangely enough, the javadoc for InterruptedIOException says: "An InterruptedIOException is thrown to indicate that an input or output transfer has been terminated because the thread performing it was interrupted."[1] But the subclass SocketTimeoutException is used differently - here's an example from sun.net.httpserver.request: /** * block() only called when available==0 and buf is empty */ private synchronized void block () throws IOException { long currtime = server.getTime(); long maxtime = currtime + readTimeout; while (currtime < maxtime) { if (selector.select (readTimeout) == 1) { selector.selectedKeys().clear(); available (); return; } currtime = server.getTime(); } throw new SocketTimeoutException ("no data received"); } So it seems that SocketTimeoutExceptions get thrown not upon thread interruptions, but a certain time after a blocking read is started. [1] http://java.sun.com/javase/6/docs/api/java/io/InterruptedIOException.html From cowwoc at bbs.darktech.org Fri May 15 11:06:53 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 13:06:53 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0DA0F4.9050203@bbs.darktech.org> References: <4A0DA0F4.9050203@bbs.darktech.org> Message-ID: <4A0DA12D.2050303@bbs.darktech.org> Forgot to CC the list. Gili cowwoc wrote: > > "Thread was interrupted" does not necessarily mean > Thread.interrupt(). It just means that the operation (run by the thread) > was interrupted. If you read the beginning sentence for > InterruptedIOException it reads "Signals that an I/O operation has been > interrupted". This says nothing about the thread itself. Michael's > subsequent post about SocketTimeoutException reinforces that point. > > By the way, I think that in general you need to interpret the > Javadoc for core classes in a broader sense than it seems. Older Javadoc > (from version 1.0) used to mention implementation details that were not > necessarily important and limited the applicability of the classes. > Newer documentation tends to go out of its way to avoid mentioning such > implementation detail and I believe that's a good thing. When > InterruptedIOException was written, Thread.interrupt() was probably the > only way to interrupt I/O operations. Nowadays there are others. Sun has > generalized its meaning over time as evident by SocketTimeoutException. > At least, that's my interpretation :) > > Gili > > Kustaa Nyholm wrote: >>> I disagree with your interpretation. Read >>> SocketTimeoutException to >>> see >>> what I mean. InterruptedIOException means the operation was interrupted, >>> not necessarily by way of Thread.interrupt(). >> >> Well SocketTimeoutException javadoc only says, very briefly: >> >> "Signals that a timeout has occurred on a socket read or accept." >> >> So that is not too helpful. But since it is derived from >> InterruptedIOException my interpretation it that they have an 'is-a' >> relationship and InterruptedIOException needs to honor the contract of >> InterruptedIOException which says: >> >> "...because the thread performing it was interrupted." >> >> To me this very specifically talks about interrupting threads with >> Thread.interrupt() >> >> >>> Returning 0 in case of timeout sounds wrong to me because it >>> is a >>> legal >>> byte value that could have been read. >> Agreed, that's what I tried to say. 0 is a legal byte value for read() to >> return so that cannot be used. For read read(byte[]) which returns the >> number of bytes read 0 could be used but there again 0 can be returned >> if 0 >> byte[] size is 0. So there again 0 is not a good option. >> >>> Returning -1 also sounds wrong to >>> me because this isn't strictly the end of stream. >> Like I said, it isn't strictly the end of stream. But also does not >> forbid treating it as (temporary) end of stream. >> >>> BufferedInputStream >>> and others assume that once you reach the end of stream you will never >>> see more data, ever. >> Can you provide a reference for that. >> >>> As far as I know, the core APIs are written in >>> terms of throwing InterruptedIOException for timeouts. >> Would also like to see something to support that. >> >> >> The behavior of throwing an exception on timeout is also a little bit >> problematic, consider: >> >> byte buf[1000]; >> int n=ins.read(buf); >> // do something with the n bytes received >> >> What happens if a timeout occurs before we have received 1000 bytes? >> >> If an exception is thrown then the user of the read() needs to handle >> the bytes received in two places or else those last <1000 bytes are lost. >> A better solution would be to return the bytes received so far and throw >> the exception on the next call (if any). But the main point is that >> neither of these case obviously correct and neither is specified in the >> javadocs. Where as a lot of code that just handles the return value >> of read(byte[]) correctly works without any further ado. >> >> >> >> The main thing is that I think we should not break existing applications, >> which I expect are not handling InterruptedIOException but many of >> which may >> depend on getting back -1 in case of timeouts. >> >> It has been a while since I used the javax.javacomm but I seem to recall >> that it returned -1 and I think this is the defining standard. >> >> I expect most rxtx users are more interested in compatibility and >> stability >> than semantic niceties and improving the API. >> >> br Kusti >> >> >> > From johnny.luong at trustcommerce.com Fri May 15 13:16:15 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Fri, 15 May 2009 12:16:15 -0700 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0DA12D.2050303@bbs.darktech.org> References: <4A0DA0F4.9050203@bbs.darktech.org> <4A0DA12D.2050303@bbs.darktech.org> Message-ID: <4A0DBF7F.50808@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 cowwoc wrote: | Forgot to CC the list. | | Gili | | cowwoc wrote: |> "Thread was interrupted" does not necessarily mean |> Thread.interrupt(). It just means that the operation (run by the thread) |> was interrupted. If you read the beginning sentence for |> InterruptedIOException it reads "Signals that an I/O operation has been |> interrupted". This says nothing about the thread itself. Michael's |> subsequent post about SocketTimeoutException reinforces that point. |> |> By the way, I think that in general you need to interpret the |> Javadoc for core classes in a broader sense than it seems. Older Javadoc |> (from version 1.0) used to mention implementation details that were not |> necessarily important and limited the applicability of the classes. |> Newer documentation tends to go out of its way to avoid mentioning such |> implementation detail and I believe that's a good thing. When |> InterruptedIOException was written, Thread.interrupt() was probably the |> only way to interrupt I/O operations. Nowadays there are others. Sun has |> generalized its meaning over time as evident by SocketTimeoutException. |> At least, that's my interpretation :) |> |> Gili |> |> Kustaa Nyholm wrote: |>>> I disagree with your interpretation. Read |>>> SocketTimeoutException to |>>> see |>>> what I mean. InterruptedIOException means the operation was interrupted, |>>> not necessarily by way of Thread.interrupt(). |>> Well SocketTimeoutException javadoc only says, very briefly: |>> |>> "Signals that a timeout has occurred on a socket read or accept." |>> |>> So that is not too helpful. But since it is derived from |>> InterruptedIOException my interpretation it that they have an 'is-a' |>> relationship and InterruptedIOException needs to honor the contract of |>> InterruptedIOException which says: |>> |>> "...because the thread performing it was interrupted." |>> |>> To me this very specifically talks about interrupting threads with |>> Thread.interrupt() |>> |>> |>>> Returning 0 in case of timeout sounds wrong to me because it |>>> is a |>>> legal |>>> byte value that could have been read. |>> Agreed, that's what I tried to say. 0 is a legal byte value for read() to |>> return so that cannot be used. For read read(byte[]) which returns the |>> number of bytes read 0 could be used but there again 0 can be returned |>> if 0 |>> byte[] size is 0. So there again 0 is not a good option. |>> |>>> Returning -1 also sounds wrong to |>>> me because this isn't strictly the end of stream. |>> Like I said, it isn't strictly the end of stream. But also does not |>> forbid treating it as (temporary) end of stream. |>> |>>> BufferedInputStream |>>> and others assume that once you reach the end of stream you will never |>>> see more data, ever. |>> Can you provide a reference for that. |>> |>>> As far as I know, the core APIs are written in |>>> terms of throwing InterruptedIOException for timeouts. |>> Would also like to see something to support that. |>> |>> |>> The behavior of throwing an exception on timeout is also a little bit |>> problematic, consider: |>> |>> byte buf[1000]; |>> int n=ins.read(buf); |>> // do something with the n bytes received |>> |>> What happens if a timeout occurs before we have received 1000 bytes? |>> |>> If an exception is thrown then the user of the read() needs to handle |>> the bytes received in two places or else those last <1000 bytes are lost. |>> A better solution would be to return the bytes received so far and throw |>> the exception on the next call (if any). But the main point is that |>> neither of these case obviously correct and neither is specified in the |>> javadocs. Where as a lot of code that just handles the return value |>> of read(byte[]) correctly works without any further ado. |>> |>> |>> |>> The main thing is that I think we should not break existing applications, |>> which I expect are not handling InterruptedIOException but many of |>> which may |>> depend on getting back -1 in case of timeouts. |>> |>> It has been a while since I used the javax.javacomm but I seem to recall |>> that it returned -1 and I think this is the defining standard. |>> |>> I expect most rxtx users are more interested in compatibility and |>> stability |>> than semantic niceties and improving the API. |>> |>> br Kusti |>> |>> |>> | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi, Maybe a better approach (improving the API) would be to consider implementing a NIO interface atop the underlying serial communication... ~ if someone desires the existing behavior, then they use a facade that lies atop of the NIO and provide the same quirks associated with it. As I see it, the implementation overrides the general contract of the InputStream to provide for the timeout functionality and it would be somewhat troublesome to expect a user of that API to catch subclasses of IOException. Best, Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoNv38ACgkQnQTBLXttTeWZ+wCeO4CTrI5l+vLPrjHl8fBj7FOL Ft8AnjQ7bXnvMhOlwZdK5CYAuoQeQ9u0 =QAax -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon May 18 03:49:50 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 11:49:50 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <20090518094950.GG17036@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, May 15, 2009 at 17:22 +0300: > >From the javadoc for InputStream: > > Since character timeout is not an indication of EOF condition I > guess one could argue that 0 should be returned in case of > timeout. A blocking operation logically has no timeout. It is blocking. Forever, until EOF or an error. This IMHO renders usage of read() useless and read(byte[]) must be used (or no InputStream). > On the other hand one could also argue that since no data was > available (if it timed out) IMHO, read() must not time out. What would happen with a small simple console app that is relying that InputStream is implemented as required by specification? It cannot tell `no byte was received but this is not an error, please call me again' - and why should it? I think, if this is not suited, i.e. if the application may want a byte but also may not want a byte, no blocking function must be invoked, but a select must be called instead or, if no select-style function is avialable, polling must be used. This is the InputStream way (block or poll). For streams the `may or may not want a byte' may sound unlikely, but in practice this is what happens, for instance, if there is some CANCEL button in a GUI or so. Closing the stream often also is no option because it cannot be reopend but it might be needed again later. In classic unix apps often signals were used (read(2) can return EINTR), but in Java this isn't possible AFAIK. EINTR IMHO has not much relation to InterruptedIOException and I think InterruptedIOException cannot be `enforced' without doing harm. > It goes against my grain to think that I get an exception when > I've set up a timeout yeah, I thought the same and when I hit this InputStream the first time I though: ohh, a bug. Or a bunch of :-) As specified, InputStream has no timeout. If you set a timeout, then somewhere else (e.g. a sub class). In this case, the sub class should also offer a way to wait for this timeout (e.g. a select style function). In practice, this makes not much sense, leaving the options not to use it at all (but what else then?) or to violate the specification. Unfortunately it seems that subclasses add setTimeout but no select() or tryRead() or simply a available()-style with a timeout parameter. Then applications would simply use this subclasses. In practice, then it does not help that they derive InputStream at all, so personally I think they should not derive from it but instead define something with a meaning :-) But I think in practice, for read(byte[]) returning 0 (e.g. in case of [intercharacter] timeout) for many people seems straightforward - so this is probably what most people will expect. (an interesting question is how those bugs happend to the Java guys, because those topics are well known since ages and solved, for instance, in the BSD socket API, but probably they didn't know it. It took years but now it seems they understood and tried it again by some NIO which is more in the `usual way'. Next version might be usable - I wouldn't be surprised if this one then is BSD socket API alike :-) SCNR). So in practice I think: - don't use read() but read(byte[]) or read(byte[], int, int) - handle `0 bytes read' situation - polling avialable() in practice may often not be suited because avialable() has no timeout parameter and if response time is important, small polling intervals would be needed which generate load - try to avoid using InputStream (from applications) directly because it sucks and it is /not/ generic (implementations may interpret it differently because it MUST be interpreted because the specification makes not much sense in many cases) - IOException and InterruptedIOException are for I/O error situations. Additionally I think, InterruptedIOException.bytesTransferred cannot be reliable because there are cases where the OS cannot surely know this and thus cannot tell it the JVM also, peer may have not received them even if they were sent As far as I know this is exactly what rxtx is doing. When having many clients this require many threads and might be less performant, so best is not to have one thousand serial ports :-) Returning 0 here IMHO also is the only option that does not `directly' violate the spec. It tells `there is an attempt to read at least one byte.' so someone could argue that the dear computer `attempted but found no time to do so' :-) > So I'm against changing this behavior. I expect a lot of code > depend on the -1 or at least on not getting an exception when a > timeout occurs. Yes, I agree, -1 means End of file (or closed by peer) and exceptions are for errors. If exceptions should be added I think it could be made configurable. For instance by some Rs232InputStream.enableException(IOException e), store this exception and later if (e != null) throw e.clone() or so. > I do not think this matches the case for serial port receive character > timeout. I read the javadoc above so that I get this exception when the > thread in my code that is performing a read or write operation gets > interrupted by Thread.interrupt(). And this is used to handle exactly that > case: being able to gracefully and cleanly interrupt threads. (well, I think Thread.interrupt() also is a big topic on its own and I'm afraid there is no really reliable mechanism for `cleanly interrupt threads' and maybe even that logically threads cannot be interrupted cleanly at all) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From rxtx at qbang.org Mon May 18 05:17:08 2009 From: rxtx at qbang.org (VIAGRA ® Official Site) Date: Mon, 18 May 2009 05:17:08 -0600 Subject: [Rxtx] DISCOUNT ID42992 75% 0FF on Pfizer ! Message-ID: <200905181117.n4IBH8ku024296@rxtx.qbang.org> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/4c172d08/attachment-0006.html From Kustaa.Nyholm at planmeca.com Mon May 18 07:20:40 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 18 May 2009 16:20:40 +0300 Subject: [Rxtx] InputStream timeouts Message-ID: Oops, sorry sent this to Steffen directly instead of mailing list. So here for the list: > A blocking operation logically has no timeout. It is blocking. > Forever, until EOF or an error. This IMHO renders usage of read() > useless and read(byte[]) must be used (or no InputStream). This is true, however read(byte[]) too is blocking so logically that (allowing it to return with value 0 in case of timeout) is no better (or worse) than read(). According to InputsStream javadoc only when byte[].length is 0 is read(byte[]) non blocking and can return 0. But to be clear: I'm in favor of returning 0 in case of timeouts for read(byte[]) and -1 for read(). > >> On the other hand one could also argue that since no data was >> available (if it timed out) > > IMHO, read() must not time out. IMHO read() should behave consistently with respect to the other read(...) methods. If we allow them to timeout, we should also allow read() to timeout. And in that case we need a return value that separates that case from normal return value (0-255), so -1 seems like a good candidate. > What would happen with a small > simple console app that is relying that InputStream is > implemented as required by specification? It cannot tell `no byte > was received but this is not an error, please call me again' > - and why should it? I think that the simple console app would be just fine, because timeouts are disabled by default so the simple applications are not affected. > > In practice, this makes not much sense, leaving the options not > to use it at all (but what else then?) or to violate the > specification. The javadoc for CommPort.getInputStream() spells out the rules for timeouts: http://java.sun.com/products/javacomm/reference/api/javax/comm/CommPort.html #getInputStream() So, IMO, while it is interesting to discuss these things the javacomm specs is quite clear about blocking behavior and although there is some conflict between how (file) inputstream behaves and Commport inputstreams behave, I think rxtx should adhere to the javacomm spec. > But I think in practice, for read(byte[]) returning 0 (e.g. in > case of [intercharacter] timeout) for many people > seems straightforward - so this is probably what most people will > expect. Agreed, I'm 100% sure there are lots of people out there that use timeouts and depend on the current behavior. Changing this would not help them but infuriate them. > > (well, I think Thread.interrupt() also is a big topic on its own > and I'm afraid there is no really reliable mechanism for > `cleanly interrupt threads' and maybe even that logically > threads cannot be interrupted cleanly at all) Would be interesting to discuss that too but that is beyond the topic of this thread. However I still believe that the InterruptedIOException was introduced so that blocking IO calls could gracefully 'return' if the calling thread was interrupted. Weather this is reliable or clean or graceful could be discussed but to me it seem reasonable. If you have a thread that is blocking on some I/O we need a mechanism that allows stopping that thread in a controlled manner and InterruptedIOException seems to provide this. cheers Kusti From Steffen.DETTMER at ingenico.com Mon May 18 09:18:37 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 17:18:37 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <20090518151837.GS17036@elberon.bln.de.ingenico.com> [OT] * Kustaa Nyholm wrote on Mon, May 18, 2009 at 16:20 +0300: > > A blocking operation logically has no timeout. It is blocking. > > Forever, until EOF or an error. This IMHO renders usage of read() > > useless and read(byte[]) must be used (or no InputStream). > This is true, however read(byte[]) too is blocking so logically that > (allowing it to return with value 0 in case of timeout) is no better > (or worse) than read(). According to InputsStream javadoc only when > byte[].length is 0 is read(byte[]) non blocking and can return 0. I think the essential difference is that for read(byte[]) returning 0 is somewhat clear, but for read() 0 is a valid byte and thus it would be a horrible mess to also use it for timeouts :) > >> On the other hand one could also argue that since no data was > >> available (if it timed out) > > > > IMHO, read() must not time out. > > IMHO read() should behave consistently with respect to the > other read(...) methods. If we allow them to timeout, we should > also allow read() to timeout. And in that case we need a return > value that separates that case from normal return value (0-255), > so -1 seems like a good candidate. Well, but then this is not consistently to EOF handling... (and if read() cannot be consistent, maybe not using it at all is an option?) > > What would happen with a small simple console app that is > > relying that InputStream is implemented as required by > > specification? It cannot tell `no byte was received but this > > is not an error, please call me again' - and why should it? > I think that the simple console app would be just fine, because > timeouts are disabled by default so the simple applications are > not affected. Not setting timeouts IMHO does not mean no timeouts will be applied but that some default timeout is used instead, which could be infinite or some OS value, which in turn may be configurable (like the TCP wait timeouts). > > In practice, this makes not much sense, leaving the options not > > to use it at all (but what else then?) or to violate the > > specification. > > The javadoc for CommPort.getInputStream() spells out the rules for > timeouts: > > http://java.sun.com/products/javacomm/reference/api/javax/comm/CommPort.html > #getInputStream() > So, IMO, while it is interesting to discuss these things > the javacomm specs is quite clear about blocking behavior > and although there is some conflict between how (file) inputstream > behaves and Commport inputstreams behave, I think rxtx should > adhere to the javacomm spec. I think first this does not clearly state what happens a read caller when a timeout occures and second IMHO it does violate the InputStream specification contract (API/javadoc). Formally speaking, it is a bug :-) Also those `advisory methods' in a formal interface are bad, I think. But another topic and discussed already several times :) Yes, in the end it seems the clear correct possiblity (no timeouts) makes no sense, so something pragmatic is needed :-) > > But I think in practice, for read(byte[]) returning 0 (e.g. in > > case of [intercharacter] timeout) for many people > > seems straightforward - so this is probably what most people will > > expect. > Agreed, I'm 100% sure there are lots of people out there that > use timeouts and depend on the current behavior. Changing this > would not help them but infuriate them. yeah, and when shifting to another type of InputStream suddenly they may break, rendering that interface a bit useless, but this is all we have... Correct IMHO would be that the compiler is able to check whether an interface supports timeouts or not (i.e. all methods exist and work as specified or a different interface must be used. Lets say we would have InputStream and InputStreamTimeout or whatever, there would be so many possibilities, but most with own disadvantages). Well, I wonder why they did not even add a timeout parameter to available() and why they forgot about write timeouts completely (also there is no counterpart to available()). Anyway. > > (well, I think Thread.interrupt() also is a big topic on its own > > and I'm afraid there is no really reliable mechanism for > > `cleanly interrupt threads' and maybe even that logically > > threads cannot be interrupted cleanly at all) > Would be interesting to discuss that too but that is beyond the > topic of this thread. However I still believe that the > InterruptedIOException was introduced so that blocking > IO calls could gracefully 'return' if the calling thread > was interrupted. Yes, maybe they forgot it in first place, then found that read can throw IOExceptions only and thus invented InterruptedIOException for InterruptedException-alike cases? but anyway. > Weather this is reliable or clean or graceful could be > discussed but to me it seem reasonable. (With not reliable I mean, when for instance you wanted to write 10 byte and you get this exception telling 5 byte have been written, you cannot be sure what this means. Maybe the 6th byte is in a fifo or whatever. I think best is to avoid the need to handle this). > If you have a thread that is blocking on some I/O we need a > mechanism that allows stopping that thread in a controlled > manner and InterruptedIOException seems to provide this. I think also this is not reliable, because even if the JVM knows a thread is supposed to be `killed', I see at least two issues: first is that native code may be active and cannot be forced to return and second it could be that the thread would need to perform clean up tasks, and since Java does not support RAII (destructors cannot clean), at least you get in trouble when exceptions happening during this cleanup (i.e. exceptions after the thread stops). This in turn IMHO is likely to happen because a well-known situation to interrupt such a thread might be after some error, and after errors exceptions I think happen more often (because less well tested and others). Let's say the thread uses an InputStream (owned by someone else) and now discards it by calling it's close (which should be a delete - because what is an input stream which is closed? Obviously it is not an input stream anymore :-)). Now you might have a special InputStream requiring special things (it might be a protocol requiring some final quit message to be sent, it might need not to close it if used by someone else, too, additional actions may be needed). Logically this could be implemented (turing complete language :-)), but in practice it might not be possible, simply because too complex (to do it right in all circumstances). oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Mon May 18 10:02:39 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 18 May 2009 19:02:39 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: > Not setting timeouts IMHO does not mean no timeouts will be > applied but that some default timeout is used instead, which > could be infinite or some OS value, which in turn may be > configurable (like the TCP wait timeouts). > The javadoc says: "By default, receive timeout is not enabled." and "By default, receive threshold is not enabled." thus (from getInputStream javadoc): "block until any data is available" which is consistent InputStream contract. > I think first this does not clearly state what happens a read > caller when a timeout occures That is true. > and second IMHO it does violate the > InputStream specification contract (API/javadoc). Formally > speaking, it is a bug :-) Agreed, but I think given the advantages you get by using InputStream (as means of reading the serial port as opposed to coming up with some totally new Stream concept) I think this was reasonable compromise and bending of the rules. > yeah, and when shifting to another type of InputStream suddenly > they may break, rendering that interface a bit useless, but this > is all we have... Exactly. > (With not reliable I mean, when for instance you wanted to write > 10 byte and you get this exception telling 5 byte have been > written, you cannot be sure what this means. Maybe the 6th byte > is in a fifo or whatever. I think best is to avoid the need to > handle this). I think all we can assume is that at least 5 bytes have been written into the native driver, weather they are in the fifo or whatever we cannot know. But as you wrote, best avoid depending on this behaviour. > I think also this is not reliable, because even if the JVM knows > a thread is supposed to be `killed', I see at least two issues: > first is that native code may be active and cannot be forced to > return Yes, but this is sort of implementation detail, not an API or Java design issue. The JVM and system class implementations should guarantee this (I bet they don't, consistently, for all platforms and OSes). > and second it could be that the thread would need to > perform clean up tasks, and since Java does not support RAII > (destructors cannot clean), at least you get in trouble when > exceptions happening during this cleanup (i.e. exceptions after > the thread stops). I sort of see what you mean, but still I do not see how this could happen if the cleanup catches exceptions properly. But then I've not studied this in detail. > This in turn IMHO is likely to happen because > a well-known situation to interrupt such a thread might be after > some error, and after errors exceptions I think happen more often > (because less well tested and others). > > Let's say the thread uses an InputStream (owned by someone else) > and now discards it by calling it's close (which should be a > delete - because what is an input stream which is closed? > Obviously it is not an input stream anymore :-)). > Now you might have a special InputStream requiring special things > (it might be a protocol requiring some final quit message to be > sent, it might need not to close it if used by someone else, > too, additional actions may be needed). > Logically this could be implemented (turing complete language :-)), > but in practice it might not be possible, simply because too > complex (to do it right in all circumstances). Ok, I think I understand what you mean: you are saying that what mention aboce "if the cleanup catches exceptions properly" maybe be and often is too difficult/complex to implement and test properly? Yeah, seen that, been there, fallen for it... cheers Kusti From Steffen.DETTMER at ingenico.com Mon May 18 10:39:26 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 18:39:26 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: <20090518163925.GV17036@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Mon, May 18, 2009 at 19:02 +0300: > > Not setting timeouts IMHO does not mean no timeouts will be > > applied but that some default timeout is used instead, which > > could be infinite or some OS value, which in turn may be > > configurable (like the TCP wait timeouts). > > > The javadoc says: > "By default, receive timeout is not enabled." > and > "By default, receive threshold is not enabled." mmm... but they are optional, so what if a driver does not support timeouts but underlaying comm interface does? anyway, *I* would not rely (but loop) but maybe this is not needed. > > and second IMHO it does violate the > > InputStream specification contract (API/javadoc). Formally > > speaking, it is a bug :-) > Agreed, but I think given the advantages you get by using > InputStream (as means of reading the serial port as opposed > to coming up with some totally new Stream concept) I think > this was reasonable compromise and bending of the rules. I don't like InputStream at all. I think it is not an abstraction to remove and later re-add (hack in) needing things. I dislike that noone knows whether it streams bytes or chars or unicode or whatever. Also, I'm used birectional things (`all things are files') for communications, I think it is simpler. So InputStream IMHO is oversimplified. Maybe it was inspired by unix line discipline (but you can select it :-)). Who knows. Anyway. > > I think also this is not reliable, because even if the JVM knows > > a thread is supposed to be `killed', I see at least two issues: > > first is that native code may be active and cannot be forced to > > return > Yes, but this is sort of implementation detail, not an API or > Java design issue. The JVM and system class implementations should > guarantee this (I bet they don't, consistently, for all platforms > and OSes). I think when no reasonable implementation is possible, probably the design is not good. If there is no reasonable way to shutdown (kill) a thread (which is the case IMHO), it makes not much sense to design it. Instead, some mechanism would be needed. I guess the InterruptedException in fact is such a kind of mechanism. I'm not sure but I think Java itself disencourages to use it. > > and second it could be that the thread would need to > > perform clean up tasks, and since Java does not support RAII > > (destructors cannot clean), at least you get in trouble when > > exceptions happening during this cleanup (i.e. exceptions after > > the thread stops). > I sort of see what you mean, but still I do not see how this > could happen if the cleanup catches exceptions properly. But > then I've not studied this in detail. > Ok, I think I understand what you mean: you are saying that > what mention aboce "if the cleanup catches exceptions properly" > maybe be and often is too difficult/complex to implement and > test properly? Yes, since it should work for any implementation, it should work for InputStreams that call abitrary complex read operations. I have applications where the read leads to some CORBA calls to a remote C++ application which also has its complexity. Now in some finally {} exceptions can occure, for instance during member destruction (closing). For example, if you have a facade like implementation with: { old = setMyLogLevel(off); for (i=0; i Yeah, seen that, been there, fallen for it... (welcome in the club :-)) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bill7007 at gmail.com Mon May 18 11:08:45 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 18 May 2009 13:08:45 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090518151837.GS17036@elberon.bln.de.ingenico.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: I can add this thought, I think the timeout is part of a protocol, which should sit above RXTX. The main feature needed in RXTX to support a protocol using timeouts is a way to interrupt it into a known state, like a reset() function. The function should cause an exception to any associated thread that was waiting on IO, maybe a unique exception due to reset() call. An IO (as opposed to Interrupted) exception may be better since the reset() has to leave a known state which may affect IO in progress. I helped work a similar situation in a CAN bus protocol. In the protocol, a send would be followed by a wait for receive. A timeout thread was enabled which caused an "alarm" event to any registered handlers upon timeout. A receive canceled the timeout alarm. The timing and thread coordination is tricky but that is all left to the protocol code. The protocols timeout event handler reset the CAN controller to get it into a known state for a retry. The reset caused an IO exception to the waiting read thread which could check that a timeout had caused it. So, if timeout is considered part of a higher level protocol class, read and write don't need special interface features as long as there is a way for a waiting state in native code to be forced to exit in a reliable, detectable, manner. +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/c9b25045/attachment-0005.html From johnny.luong at trustcommerce.com Mon May 18 11:49:53 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 18 May 2009 10:49:53 -0700 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: <4A119FC1.3090700@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Johnson wrote: | I can add this thought, I think the timeout is part of a protocol, which | should sit above RXTX. The main feature needed in RXTX to support a protocol | using timeouts is a way to interrupt it into a known state, like a reset() | function. The function should cause an exception to any associated thread | that was waiting on IO, maybe a unique exception due to reset() call. An IO | (as opposed to Interrupted) exception may be better since the reset() has to | leave a known state which may affect IO in progress. | | I helped work a similar situation in a CAN bus protocol. In the protocol, a | send would be followed by a wait for receive. A timeout thread was enabled | which caused an "alarm" event to any registered handlers upon timeout. A | receive canceled the timeout alarm. The timing and thread coordination is | tricky but that is all left to the protocol code. The protocols timeout | event handler reset the CAN controller to get it into a known state for a | retry. The reset caused an IO exception to the waiting read thread which | could check that a timeout had caused it. | | So, if timeout is considered part of a higher level protocol class, read and | write don't need special interface features as long as there is a way for a | waiting state in native code to be forced to exit in a reliable, detectable, | manner. | | +BillJ | | | | ------------------------------------------------------------------------ | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx Hi Bill, This is all conjecture and probably a lot of work in practice, so its just a train of thought at this point (via NIO)... Supposer SerialPort were to implement a method that returned "SerialPortChannel" which worked along similar lines as a SocketChannel. ~ Then you could in practice, have a Selector object that did the timeout you described above (via a register method)... your read and write methods could block or not block and it would be a lot easier to drive multiple serial ports than what you have today. - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoRn8EACgkQnQTBLXttTeXm0gCfaua0ej3Rt0fogRR68bbEFG0Z BTwAn1s79U8ZU0yj6xcND8gyHzDmKKqq =ThWj -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon May 18 11:54:10 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 19:54:10 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: <20090518175409.GW17036@elberon.bln.de.ingenico.com> (OT) * Bill Johnson wrote on Mon, May 18, 2009 at 13:08 -0400: > I can add this thought, I think the timeout is part of a > protocol, which should sit above RXTX. Probably actually on both levels timeouts can be helpful; if there is some PPP/TCP or other full duplex multiplexing protcol I think at least it is nice to be able to read with some reasonable timeout(s). > I helped work a similar situation in a CAN bus protocol. In the > protocol, a send would be followed by a wait for receive. A > timeout thread was enabled which caused an "alarm" event to > any registered handlers upon timeout. A receive canceled the > timeout alarm. The timing and thread coordination is tricky but > that is all left to the protocol code. (this Bosch car protocol?) But if the protocol implementation knows the timeout value, wouldn't it be easier and suited better to have some way to apply it to the reads without needing multithreading? Was the implementation in Java? How to cancel the receive by the timeout alarm? Was it (protocol thread implementation) internally polling? You said later, `a way for a waiting state in native code to be forced to exit in a reliable, detectable, manner'. Sounds complicated :) Is this a generic requirement? I think, protocols often can be implemented to use InputStream (or some other interface) but also to offer the same interface (like the decorator pattern). At least when `stacking' such protocols it can become quite difficult, even if having an own thread per protocol instance. Of course heavily depends on the project and situation. Well, interesting topic :) > The protocols timeout event handler reset the CAN controller to > get it into a known state for a retry. The reset caused an IO > exception to the waiting read thread which could check that a > timeout had caused it. Ohh, the CAN controller must be reset? Though they would handle a whole frame automatically. I have no clue about this; surely it is very specific and complex. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bill7007 at gmail.com Mon May 18 12:25:19 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 18 May 2009 14:25:19 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A119FC1.3090700@trustcommerce.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <4A119FC1.3090700@trustcommerce.com> Message-ID: Hi Johnny, I think a SerialPortChannel could be a good example. It uses an underlying Socket which uses an underlying implementation to support open, timeouts, etc. As part of the implementation is where the current RXTX could come in, provided there is a way to back out of a blocking situation. +BillJ On Mon, May 18, 2009 at 1:49 PM, Johnny Luong < johnny.luong at trustcommerce.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Bill Johnson wrote: > | I can add this thought, I think the timeout is part of a protocol, which > | should sit above RXTX. > ... > > Hi Bill, > > This is all conjecture and probably a lot of work in practice, so its > just a train of thought at this point (via NIO)... > > Supposer SerialPort were to implement a method that returned > "SerialPortChannel" which worked along similar lines as a SocketChannel. > ~ Then you could in practice, have a Selector object that did the timeout > you described above (via a register method)... your read and write > methods could block or not block and it would be a lot easier to drive > multiple serial ports than what you have today. > > - -Johnny > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkoRn8EACgkQnQTBLXttTeXm0gCfaua0ej3Rt0fogRR68bbEFG0Z > BTwAn1s79U8ZU0yj6xcND8gyHzDmKKqq > =ThWj > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/0a44a920/attachment-0005.html From lyon at docjava.com Mon May 18 13:18:53 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 18 May 2009 15:18:53 -0400 Subject: [Rxtx] image capture In-Reply-To: References: Message-ID: Hi All, I know this is off-topic, but we have so many native method interface experts here, I just had to ask; Is anyone able to do image capture on a 64 bit mac, using Java? QT4J is not loadable using Java 6 (AFAIK). Thanks! - Doug From bill7007 at gmail.com Mon May 18 13:24:04 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 18 May 2009 15:24:04 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090518175409.GW17036@elberon.bln.de.ingenico.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> Message-ID: On Mon, May 18, 2009 at 1:54 PM, Steffen DETTMER < Steffen.DETTMER at ingenico.com> wrote: > (OT) > > * Bill Johnson wrote on Mon, May 18, 2009 at 13:08 -0400: > > I can add this thought, I think the timeout is part of a > > protocol, which should sit above RXTX. > > Probably actually on both levels timeouts can be helpful; if > there is some PPP/TCP or other full duplex multiplexing protcol I > think at least it is nice to be able to read with some reasonable > timeout(s). I think timeout at the native level does not fit well with a read() concept of timeout because it depends on the protocol not really on the read(). > > > I helped work a similar situation in a CAN bus protocol. In the > > protocol, a send would be followed by a wait for receive. A > > timeout thread was enabled which caused an "alarm" event to > > any registered handlers upon timeout. A receive canceled the > > timeout alarm. The timing and thread coordination is tricky but > > that is all left to the protocol code. > > (this Bosch car protocol?) > > But if the protocol implementation knows the timeout value, > wouldn't it be easier and suited better to have some way to apply > it to the reads without needing multithreading? > If you are waiting on a read and you are waiting on a timeout at the same time, that is two logical threads. Maybe you are looping check for one of two condition, character or timeout, but I think its the same logically as waiting for a character or a timeout exception. It is a special case where you try to read except if it take too long, sound a little like code? > Was the implementation in Java? How to cancel the receive by the > timeout alarm? Was it (protocol thread implementation) internally > polling? > The CAN bus was Java on a TINI embedded system for a warehouse system. It implemented a guaranteed delivery data path patterned after the Datagram interface, I called it a Cangram :-) The problem was how to cancel a read as part of a detected protocol or controller error. The hardware was reset via the native code driver which released resources so a restart was successful. I may have garbaged a thread and started a new one as part of it. > > You said later, `a way for a waiting state in native code to > be forced to exit in a reliable, detectable, manner'. Sounds > complicated :) Is this a generic requirement? I think, protocols > often can be implemented to use InputStream (or some other > interface) but also to offer the same interface (like the > decorator pattern). At least when `stacking' such protocols it > can become quite difficult, even if having an own thread per > protocol instance. Of course heavily depends on the project and > situation. Well, interesting topic :) > I think it (reset, stop, interrupt, whatever) should be a general requirement for any Java native interface code. Without it, your application can lock up and there is no reasonable way to regain control. > > The protocols timeout event handler reset the CAN controller to > > get it into a known state for a retry. The reset caused an IO > > exception to the waiting read thread which could check that a > > timeout had caused it. > > Ohh, the CAN controller must be reset? Though they would handle a > whole frame automatically. > I have no clue about this; surely it is very specific and complex. > The native interface resets it. In most cases, the only reason to reset it was so the native interface was freed up for a retry. If they had a interrupt() function, that may have been better. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. > This message may contain confidential and/or privileged information. If > you are not the addressee or authorized to receive this for the addressee, > you must not use, copy, disclose or take any action based on this message or > any information herein. If you have received this message in error, please > advise the sender immediately by reply e-mail and delete this message. Thank > you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/7df09a1e/attachment-0005.html From beat.arnet at gmail.com Mon May 18 13:27:07 2009 From: beat.arnet at gmail.com (Beat Arnet) Date: Mon, 18 May 2009 15:27:07 -0400 Subject: [Rxtx] Error 0x3e3 at termios.c(1301) Message-ID: All, I am experiencing a situation in which RXTX crashes consistently (both with 2.1 and 2.2). Steps to reproduce: - computer with JAVA program is sending bytes over RS-232 to embedded device, embedded device is off - embedded device powers up and transmit startup banner - JVM crashes: Error 0x3e3 at termios.c(1301) Any idea of what I should be looking for? Thanks! Beat # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6163696c, pid=808, tid=9648 # # Java VM: Java HotSpot(TM) Client VM (1.6.0-b105 mixed mode) # Problematic frame: # C 0x6163696c # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x0af7e400): JavaThread "Thread-4" [_thread_in_native, id=9648] siginfo: ExceptionCode=0xc0000005, reading address 0x6163696c Registers: EAX=0xffffffff, EBX=0x78652064, ECX=0x7c90f661, EDX=0x00000005 ESP=0x0c68f990, EBP=0x70706120, ESI=0x6f207469, EDI=0x6e612072 EIP=0x6163696c, EFLAGS=0x00010206 Top of Stack: (sp=0x0c68f990) 0x0c68f990: 6e6f6974 71657220 74736575 0a0a0d2e 0x0c68f9a0: 00000000 0c68f9d4 6d94556c 0daa3cb4 0x0c68f9b0: 74697277 74794265 3e0d2065 0a000a3e 0x0c68f9c0: 7c90cfea 7c80a059 000007d4 0af7e400 0x0c68f9d0: 6d909d8d 000007d4 00000002 6d945bf6 0x0c68f9e0: 0af7e400 00000001 00000000 0af8b024 0x0c68f9f0: 00000032 0af8b038 00000002 00000000 0x0c68fa00: 00000000 0af7e400 0af8b02c 06e85900 Instructions: (pc=0x6163696c) 0x6163695c: [error occurred during error reporting, step 100, id 0xc0000005] Stack: [0x0c640000,0x0c690000), sp=0x0c68f990, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C 0x6163696c [error occurred during error reporting, step 120, id 0xc0000005] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeByte(IZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write(I)V+86 j codeskin.serial.SerialPortRxtx2_1.write(I)V+29 j codeskin.c2oooprog.BootLoader2xxx$PingTask.run()V+87 v ~StubRoutines::call_stub -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/a692f306/attachment-0005.html From cowwoc at bbs.darktech.org Mon May 18 15:43:15 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Mon, 18 May 2009 17:43:15 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <4A119FC1.3090700@trustcommerce.com> Message-ID: <4A11D673.7080508@bbs.darktech.org> I'm in favor of using SerialPortChannel for timeouts and InputStream for non-blocking reads. This will allow us to follow the specification to the letter without any funky side-effects. In my view breaking the InputStream specification is a far greater sin than throwing InterruptedIOException from read(). Using SerialPortChannel and InputStream should allow us to please people in both camps without breaking the specification. Gili Bill Johnson wrote: > Hi Johnny, > > I think a SerialPortChannel could be a good example. It uses an > underlying Socket which uses an underlying implementation to support > open, timeouts, etc. As part of the implementation is where the current > RXTX could come in, provided there is a way to back out of a blocking > situation. > > +BillJ > > On Mon, May 18, 2009 at 1:49 PM, Johnny Luong > > > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Bill Johnson wrote: > | I can add this thought, I think the timeout is part of a protocol, > which > | should sit above RXTX. > > ... > > > Hi Bill, > > This is all conjecture and probably a lot of work in practice, so its > just a train of thought at this point (via NIO)... > > Supposer SerialPort were to implement a method that returned > "SerialPortChannel" which worked along similar lines as a SocketChannel. > ~ Then you could in practice, have a Selector object that did the > timeout > you described above (via a register method)... your read and write > methods could block or not block and it would be a lot easier to drive > multiple serial ports than what you have today. > > - -Johnny > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkoRn8EACgkQnQTBLXttTeXm0gCfaua0ej3Rt0fogRR68bbEFG0Z > BTwAn1s79U8ZU0yj6xcND8gyHzDmKKqq > =ThWj > -----END PGP SIGNATURE----- > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From bschlining at gmail.com Mon May 18 21:20:25 2009 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 18 May 2009 20:20:25 -0700 Subject: [Rxtx] Fwd: image capture In-Reply-To: References: Message-ID: forgot to cc the list ---------- Forwarded message ---------- From: Brian Schlining Date: Mon, May 18, 2009 at 20:19 Subject: Re: [Rxtx] image capture To: "Dr. Douglas Lyon" > Is anyone able to do image capture on a 64 bit mac, using > Java? Yes, I'm doing it from both video capture cards (Kona and Blackmagic) as well as from movie files. I'm only doing it on Java 5 (Mac) though. > QT4J is not loadable using Java 6 (AFAIK). Are you running this on a Mac or PC? Not that it matters I guess. QT4J is (unofficially) dead. It will be officially deprecated when Mac OS X 10.6 (Snow Leopard) is released, but for all practical purposes it's passed away. With each new release of QuickTime in the past year, I do the mad scramble to work around all the changes and bugs that are introduced. I'm working on once such 'fix' right now as a matter of fact. It's too bad too, QT4J was pretty darn powerful. Your best bet going forward is to rip out the QT4J code and replace it with a Mac/PC/Linux abstraction layer. On a Mac there you could try rococoa ( https://rococoa.dev.java.net) or just grab some QTKit samples off of Apples' developer site and write a JNI or JNA interface. On a PC, not sure what to tell you. I don't know what Apple's plans are with QT4J on a PC. They are pushing everyone away from QuickTime (C API) to QTKit (Cocoa/Objective-C). But on a PC ASFAIK there is no QTKit, so it's still QuickTime in the key of C. -- B ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/913800a4/attachment-0005.html From Kustaa.Nyholm at planmeca.com Tue May 19 00:26:27 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 19 May 2009 09:26:27 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A11D673.7080508@bbs.darktech.org> Message-ID: Oops, did it again, did not send this to the list, so we go: > > I'm in favor of using SerialPortChannel for timeouts and InputStream > for non-blocking reads. This will allow us to follow the specification > to the letter without any funky side-effects. > It was not clear to me what Gili is advocating here so I felt I needed to clarify this. > > In my view breaking the InputStream specification is a far greater sin > than throwing InterruptedIOException from read(). Throwing InterruptedIOException from InputStream.read() is just as big sin as it breaks the contract of InterruptedIOException , which says that the *thread* that was performing the IO was interrupted. Coneceptually I feel throwing an exception is a big sin in a situation which is not an error. A time out in a serial communication is almost always to be excepted since it is used to deal with real, live hardware outside the computer and very often it is a part of the higher level communication protocol, for example used to package or frame messages. Exceptions should be reserved for exceptional things not used for something that the programmer expects to happen normally. For one thing they incur an overhead. Granted, in a typical 9600 baud ie 1ms/char case the overhead is negligible, but it is there. On my 2.8 GHz Core 2 Duo try/throw/catch takes about 13 usec. In my view it is simply wrong to throw an exception for timeouts in a serial port. An even greater sin would be breaking existing code for design purity, at least in this case. > Using > SerialPortChannel and InputStream should allow us to please people in > both camps without breaking the specification. > So you are advocating adding a new class SerialPortChannel and a new method SerialPort.getSerialPortChannel() ? That would be acceptable in that it would not brake existing code but totally unnecessary in my view. I suspect most people turn to rxtx as a replacement for javacomm and are only interested in getting the job done. And the current API does this with very nicely. I think we all have better use for our time than to re-invent a serial port API. If the API bothers someone, I suggest they write a wrapper to implement the improvements and release it for interested users, if any. Would be kind of fun to see them struggle with all the API design issues and see what intellectual compromises they have to concede to. As a famous film ends in the sentence: "Nobody's perfect." cheers Kusti From Steffen.DETTMER at ingenico.com Tue May 19 02:12:14 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 19 May 2009 10:12:14 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A11D673.7080508@bbs.darktech.org> Message-ID: <20090519081214.GY17036@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Tue, May 19, 2009 at 09:26 +0300: > Coneceptually I feel throwing an exception is a big sin in a situation > which is not an error. Yes, I think the same. > In my view it is simply wrong to throw an exception for timeouts in > a serial port. Yes, I agree! > An even greater sin would be breaking existing code for design > purity, at least in this case. An even greater sin than that IMHO would be if the new stuff still isn't undoubtful powerful (which would IMHO need to include the possibility to select serial, TCP and other files simultaneously on systems that support it, e.g. for multi-serial-console applications or so). > So you are advocating adding a new class SerialPortChannel and > a new method SerialPort.getSerialPortChannel() ? SerialPortChannel would be a java.nio.channels.SelectableChannel or so? Or maybe a AbstractGatheringInterruptibleSelectableReadableWritableByteChannel. (the java name for `int fd' lol - SCNR). If changeing, I think an option could be to implement straightforward in native code offering its natural API (full timeout support, maybe as mandatory parameter, not dealing with Channel, Streams, source&sink, reactor&proactor patterns :-)). On top of that then both Channel and Stream and maybe something else for someone else. > That would be acceptable in that it would not brake existing code but > totally unnecessary in my view. I suspect most people turn to rxtx > as a replacement for javacomm and are only interested in getting the > job done. Yes, and most probably just have a few simultaneous connections. Others may need to have a dedicated, specialized and highly optimized JNI impl anyway (I guess). > If the API bothers someone, I suggest they write a wrapper to > implement the improvements and release it for interested users, > if any. Yes, actually that was what we did, but sometimes it was a bit cumbersome (because of InputStream and stuff). We implemented on top of that (instead of native interfaces or such) assuming that those interfaces won't change (but JNI interfaces probably are considered implementation details and thus probably will change). > Would be kind of fun to see them struggle with all the API > design issues and see what intellectual compromises they have > to concede to. Yeah, and then a nio successor comes and everone wanna go with it then :-) oki, Steffen ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Tue May 19 02:33:35 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 19 May 2009 10:33:35 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> Message-ID: <20090519083335.GZ17036@elberon.bln.de.ingenico.com> Hi! * Bill Johnson wrote on Mon, May 18, 2009 at 15:24 -0400: > * On Mon, May 18, 2009 at 1:54 PM, Steffen DETTMER wrote: > > * Bill Johnson wrote on Mon, May 18, 2009 at 13:08 -0400: > > > I can add this thought, I think the timeout is part of a > > > protocol, which should sit above RXTX. > > > > Probably actually on both levels timeouts can be helpful; if > > there is some PPP/TCP or other full duplex multiplexing > > protcol I think at least it is nice to be able to read with > > some reasonable timeout(s). > > I think timeout at the native level does not fit well with a > read() concept of timeout because it depends on the protocol > not really on the read(). What is special about `native level' to gain a special handling? I think all levels should support timeouts. Of course the read timeout an application invokes on a TCP stream has no direct relation to a PPP timeout and intercharacter timeouts on serial lines often depend on serial speed, CPU speed, required response timings, interrupt load etc, I think. So yes, I agree that protocols (often) define needed timeouts (to the lower layer) and the lower layer must offer support for timeouts. Is this what you mean with `depends on the protocol'? > > (this Bosch car protocol?) > > > > But if the protocol implementation knows the timeout value, > > wouldn't it be easier and suited better to have some way to apply > > it to the reads without needing multithreading? > > If you are waiting on a read and you are waiting on a timeout at the same > time, that is two logical threads. Ohh no, I disagree. I think, only if you have plenty of resources it is possible to waste a whole thread to watch a clock. When you have to read 100 connections of course you can use 100 threads, but better would be 1 thread with a select (or epoll or whatever), especially when assuming that the timeout is just a wait (thread sleep) time (when the OS is buffering the data anyway, which on Java running OSes probably is common). > Maybe you are looping check for one of two condition, character > or timeout, but I think its the same logically as waiting for a > character or a timeout exception. It is a special case where > you try to read except if it take too long, sound a little like > code? But isn't a maximum time a natural property of waiting? When you wait for someone for a meeting or so, you look to your watch from time to time and after half an hour or so you leave or continue your business. Select style IMHO is logically more event based than multi-threaded synchronous, but for applications or protocol implementations I found it comfortable when timeouts can be configured at any time. We even have two optional timeout parameters on our read function which eases implementing requirements like `receive both characters within 200 ms or reply with X'. > The CAN bus was Java on a TINI embedded system for a warehouse > system. It implemented a guaranteed delivery data path > patterned after the Datagram interface, I called it a Cangram > :-) The problem was how to cancel a read as part of a detected > protocol or controller error. The hardware was reset via the > native code driver which released resources so a restart was > successful. I may have garbaged a thread and started a new one > as part of it. cool :-) guess this was a very interesting project :) > I think it (reset, stop, interrupt, whatever) should be a > general requirement for any Java native interface code. Without > it, your application can lock up and there is no reasonable way > to regain control. alternatively, it could be required that any JNI function must return after some latest amount of time (i.e. specifying the maximum invocation time). I think, third-path-interruptions, maybe triggered from different threads, could quickly make code complicated because suddenly so many possible code paths can happen and they are hard to test (and cover). Personally, I think this is a major point against avoidable thread usage (even more if threads are not orthogonal) - hard to test, hard to ensure and prove it really is wrong always. Of course often enough it is needed anyway... oki, Steffen ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From michaeltandy at googlemail.com Tue May 19 08:33:09 2009 From: michaeltandy at googlemail.com (Michael Tandy) Date: Tue, 19 May 2009 15:33:09 +0100 Subject: [Rxtx] Rxtx native library loading Message-ID: <302aa0340905190733r4009e394v335b3ef47d84ffb5@mail.gmail.com> Attached is a patch which changes native library loading in Rxtx. Specifically, it makes two changes: 1. Looks in the directory RXTXcomm.jar is in for a native library, prior to searching java.library.path 2. Produces more informative error messages (in addition to the normal exceptions) if the native library cannot be found. The key benefits of this are: (a) to simplify setup; no need for administrator access to put things in shared/system directories, just unzip a file (containing my program as a .jar, RXTXcomm.jar, rxtxSerial.dll, librxtxSerial.so, and so on) and you're good to go; (b) If you've got multiple rxtx versions on your path (e.g. MATLAB puts its bin directory on your path, containing a copy of rxtxSerial.dll) you get the library file matching your jar file; (c) you don't need a big -Djava.library.path= every time you start your program; (d) if your native library file is missing, the error message is a bit more helpful (tells you where is being searched and for what); and (e) If the new code fails, it reverts to what the old code did, so it should be fully backwards-compatible. What do you think - is it worth including these changes in the main version of rxtx? Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: libraryloader.diff Type: text/x-diff Size: 10293 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090519/641c6573/attachment-0004.bin From bill7007 at gmail.com Tue May 19 12:37:32 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Tue, 19 May 2009 14:37:32 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090519083335.GZ17036@elberon.bln.de.ingenico.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> <20090519083335.GZ17036@elberon.bln.de.ingenico.com> Message-ID: On Tue, May 19, 2009 at 4:33 AM, Steffen DETTMER wrote: ... > > Is this what you mean with `depends on the protocol'? Native code is run time speed efficient, and that is important. I think I am saying, design wise, the function is read(). Timeout is a condition on read() only required by whatever comm protocol or comm logic you are using. I am thinking the whole purpose of SerialPort object is to represent a serial port so it should only contains methods and attributes of a serial port. A timeout is an event, part of the communication logic that is using that port. Wow, what a discussion. I had to go back and read it all to gather thoughts. I see multiple issues here. They coexist. 1) CommPort timeout implementation 2) Native blocking behavior and possible interruptions I think my protocol timeout thought was to state that the CommPort timeout may not be the best way implement a protocol timeout, but an alternative needs a blocking interrupt capability. Maybe that should be its own discussion. I do agree with the commandment, Thou shalt not modify the reference API. To focus back on Sun's CommPort interface, it does define a timeout that is optionally implemented and could be useful. I think a description of CommPort.getInputStream together with InputStream.read() leads to the implementation behavior: read() returns "the next byte of data, or -1 if the end of the stream is reached." So, end of stream must mean one of: 1) a timeout 2) "framing errors" (plural meaning parity and overrun too?) read(byte[]?b) returns "the total number of bytes read into the buffer, or -1 is there is no more data because the end of the stream has been reached." An end of stream here causes a return of the number read so far, or -1 if no data was yet read. How to determine cause of end of stream is a weakness of this API. Capturing a SerialPortEvent includes the framing error but not timeout. +BillJ From Steffen.DETTMER at ingenico.com Tue May 19 13:10:26 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 19 May 2009 21:10:26 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> <20090519083335.GZ17036@elberon.bln.de.ingenico.com> Message-ID: <20090519191025.GF17036@elberon.bln.de.ingenico.com> * Bill Johnson wrote on Tue, May 19, 2009 at 14:37 -0400: > methods and attributes of a serial port. A timeout is an event, part > of the communication logic that is using that port. (or the absence of data arrived events?) > read() returns "the next byte of data, or -1 if the end of the stream > is reached." > So, end of stream must mean one of: > 1) a timeout > 2) "framing errors" (plural meaning parity and overrun too?) I think neither timeout nor framing errors are end of stream (end of file) but only `remote DTR drop' is. I'm not sure (and always confuse) to which input line its maps and whether it is hi or lo active... I think, on linux, at least some versions, this worked well because when one side called close(fd) the other side read the EOF in exactly this moment. In general I think this is not reliable (different OSes surely handle it differently and it probably depends on several other things). With TCP sockets this can be expected to work (when one side shuts down its write channel, the other reads EOF after reading all data, which of course is returned first). Well, but probably some OS out there will be different just to annoy us :-) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From cowwoc at bbs.darktech.org Tue May 19 14:28:36 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 19 May 2009 16:28:36 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <4A131674.6000906@bbs.darktech.org> Guys, I am feeling very frustrated with this whole discussion. 1) There is no doubt that the current implementation breaks the InputStream API. A return value of -1 is already mapped to end-of-stream. For this reason, you *cannot* map the same value to a timeout. This is basic design-by-contract! 2) RXTX's implementation does not match javax.comm 100%. There are plenty of situations where the two implementations diverge. I am frustrated that people want to simultaneously freeze the APIs and fix issues that *cannot* be fixed purely in the implementation layer. 3) "Premature optimization is the root of all evil" and yet I see people complaining that exception handling costs 13 usec. Java places emphasizes correctness above performance. If you don't get that you shouldn't be coding in Java. More specific replies below... > Throwing InterruptedIOException from InputStream.read() is just as > big sin as it breaks the contract of InterruptedIOException , which > says that the *thread* that was performing the IO was interrupted. A thread getting interrupted is not the same as Thread.interrupt(). My interpretation is that interrupting the operation due to a timeout is a perfectly legal form of "thread interruption". Even with respect to Thread.interrupt(), you can't interrupt a thread, only the work it is executing. > Coneceptually I feel throwing an exception is a big sin in a situation > which is not an error. Exceptions refer to "exceptional circumstances" which is not the same as "errors". By that I mean that the "normally" the method returns 0-255, but exceptional cases such as timeouts are perfectly legal. > A time out in a serial communication is > almost always to be excepted since it is used to deal with real, live > hardware outside the computer I disagree. Some application-level protocols don't use timeouts at all. Why would your argument be true for serial connections but not sockets? > So you are advocating adding a new class SerialPortChannel and > a new method SerialPort.getSerialPortChannel() ? > > That would be acceptable in that it would not brake existing code but > totally unnecessary in my view. I suspect most people turn to rxtx > as a replacement for javacomm and are only interested in getting the > job done. And the current API does this with very nicely. I think > we all have better use for our time than to re-invent a serial port > API. The classic IO api is synchronous whereas NIO channels are asynchronous. Trying to retrofit timeouts on top of the old APIs will never be as clean as using NIO which is designed specifically for this purpose. Gili From tjarvi at qbang.org Tue May 19 17:19:15 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 May 2009 17:19:15 -0600 (MDT) Subject: [Rxtx] Rxtx native library loading In-Reply-To: <302aa0340905190733r4009e394v335b3ef47d84ffb5@mail.gmail.com> References: <302aa0340905190733r4009e394v335b3ef47d84ffb5@mail.gmail.com> Message-ID: On Tue, 19 May 2009, Michael Tandy wrote: > Attached is a patch which changes native library loading in Rxtx. > > Specifically, it makes two changes: > > 1. Looks in the directory RXTXcomm.jar is in for a native library, > prior to searching java.library.path > 2. Produces more informative error messages (in addition to the normal > exceptions) if the native library cannot be found. > > The key benefits of this are: > (a) to simplify setup; no need for administrator access to put things > in shared/system directories, just unzip a file (containing my program > as a .jar, RXTXcomm.jar, rxtxSerial.dll, librxtxSerial.so, and so on) > and you're good to go; > (b) If you've got multiple rxtx versions on your path (e.g. MATLAB > puts its bin directory on your path, containing a copy of > rxtxSerial.dll) you get the library file matching your jar file; > (c) you don't need a big -Djava.library.path= every time you start your program; > (d) if your native library file is missing, the error message is a bit > more helpful (tells you where is being searched and for what); > and (e) If the new code fails, it reverts to what the old code did, so > it should be fully backwards-compatible. > > What do you think - is it worth including these changes in the main > version of rxtx? > > Michael > Hi Michael, We will be putting a patch like yours in as soon as we release 2.2. The release was going to be mothers day but I got caught up :) I hope to do it next weekend. After that we will be looking at web installs which overlaps with your solution. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 19 17:44:25 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 May 2009 17:44:25 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A131674.6000906@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> Message-ID: On Tue, 19 May 2009, cowwoc wrote: >> A time out in a serial communication is >> almost always to be excepted since it is used to deal with real, live >> hardware outside the computer > > I disagree. Some application-level protocols don't use timeouts at all. > Why would your argument be true for serial connections but not sockets? > Hi Gili One fundamental difference between sockets, file io and RS232 communication is that sockets and file systems provide error handling. If a packet is lost, it is resent without the java API knowing about it. RS232 is actually an electrical signal standard. Serial communication exposes a UART without any meaningful error handling and cludgy error reporting. Given the above, ignoring timeouts is not really a valid rxtx level option. We could have a new option/method that allows you to get an InputStream or Channel that behaves as you wish. If we change the InputStream returned by getInputStream(), that would be change in the API (version 3.0) that forks our userbase. So I guess my question is whether or not you are trying to change the object returned by getInputStream or just looking for a means to get a different object you would like to define be returned. The later is far easier to accommodate. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 19 18:38:06 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 May 2009 18:38:06 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090519191025.GF17036@elberon.bln.de.ingenico.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> <20090519083335.GZ17036@elberon.bln.de.ingenico.com> <20090519191025.GF17036@elberon.bln.de.ingenico.com> Message-ID: On Tue, 19 May 2009, Steffen DETTMER wrote: > * Bill Johnson wrote on Tue, May 19, 2009 at 14:37 -0400: >> methods and attributes of a serial port. A timeout is an event, part >> of the communication logic that is using that port. > > (or the absence of data arrived events?) > >> read() returns "the next byte of data, or -1 if the end of the stream >> is reached." >> So, end of stream must mean one of: >> 1) a timeout >> 2) "framing errors" (plural meaning parity and overrun too?) > > I think neither timeout nor framing errors are end of stream (end > of file) but only `remote DTR drop' is. I'm not sure (and always > confuse) to which input line its maps and whether it is hi or lo > active... > There really is an end of input in termios that would match up fairly close in theory. The problem is it isnt really used as far as I know. termois.c_cc[VEOF] - the end of input character. I assume it is control-d. If you have a terminal open, try typing it into the shell prompt :) We even have some access to it in rxtx as extensions to commapi: private native byte nativeGetEndOfInputChar( ) throws UnsupportedCommOperationException; private native boolean nativeSetEndOfInputChar( byte b ) throws UnsupportedCommOperationException; GPIB has an entire wire dedicated to "EOI." -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue May 19 19:07:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 19 May 2009 21:07:34 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> Message-ID: <4A1357D6.9090705@bbs.darktech.org> Hi Trent, > RS232 is actually an electrical signal standard. Serial communication > exposes a UART without any meaningful error handling and cludgy error > reporting. > > Given the above, ignoring timeouts is not really a valid rxtx level > option. We could have a new option/method that allows you to get an > InputStream or Channel that behaves as you wish. Why? You could always use available() alongside blocking reads. > If we change the InputStream returned by getInputStream(), that would be > change in the API (version 3.0) that forks our userbase. > > So I guess my question is whether or not you are trying to change the > object returned by getInputStream or just looking for a means to get a > different object you would like to define be returned. > > The later is far easier to accommodate. I expect users to use getInputStream() for blocking reads and getInputChannel() for non-blocking reads. I understand your objections and normally I'd agree to wait for version 3.0 but RXTX's violation of the specification is a critical flaw in my opinion. Don't take my word for it... Take a look at this post I just ran across: http://stackoverflow.com/questions/611760/java-inputstream-read-blocking ------ quote ------- A read of -1 isn't doesn't mean, "there's no data present on this attempt," it means, "the stream is closed and there will never be any data so stop asking." If the end of the stream has not been reached, a read() call will block, just as the documentation specifies. [...] I've only used javax.comm for serial port I/O, and it implements InputStream as intended. It's possible that the rxtx implementation violates the contract of InputStream.read(), but if so, that's a very bad thing. Any code that was written to work with InputStream in general relies on the fact that -1 means EOF. Passing a broken java.io.InputStream to such code will cause problems. If rxtx supports non-blocking I/O, they should have created their own interface for reading, not extended InputStream. ------ quote ------- We learn two things from this post: 1) javax.comm respects the InputStream contract. It does not return -1 on timeouts. Seeing how you've written that any deviation from the javax.comm implementation is a bug I would suggest that this should be fixed immediately. 2) Violating the superclass specification can introduce an untold number of bugs. For example, I spent hours trying to figure out why BufferedReader.readLine() was returning null while the connection was still open. Gili From tjarvi at qbang.org Tue May 19 19:23:13 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 May 2009 19:23:13 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A1357D6.9090705@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> Message-ID: On Tue, 19 May 2009, cowwoc wrote: > > 1) javax.comm respects the InputStream contract. It does not return -1 on > timeouts. Seeing how you've written that any deviation from the javax.comm > implementation is a bug I would suggest that this should be fixed > immediately. > Hi Gili What is the observed behavior of javax.comm on timeout? Are you sure it didn't just disable timeouts by default? -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue May 19 19:37:24 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 19 May 2009 21:37:24 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> Message-ID: <4A135ED4.3090608@bbs.darktech.org> Trent Jarvi wrote: >> 1) javax.comm respects the InputStream contract. It does not return -1 >> on timeouts. Seeing how you've written that any deviation from the >> javax.comm implementation is a bug I would suggest that this should be >> fixed immediately. > What is the observed behavior of javax.comm on timeout? Are you sure it > didn't just disable timeouts by default? I'm not sure. Unfortunately, I've never gotten javax.comm to work under Windows and I don't have access to any other platform at this time. I assume that you've used javax.comm before, so I encourage you to try it on your end. Whatever they did, I really don't think that Sun would have violated the InputStream specification by returning -1 on timeout. As the BufferedReader.readLine() example shows, doing so triggers a lot of bugs. Gili From tjarvi at qbang.org Tue May 19 20:01:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 May 2009 20:01:53 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A135ED4.3090608@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> <4A135ED4.3090608@bbs.darktech.org> Message-ID: On Tue, 19 May 2009, cowwoc wrote: > Trent Jarvi wrote: >>> 1) javax.comm respects the InputStream contract. It does not return -1 on >>> timeouts. Seeing how you've written that any deviation from the javax.comm >>> implementation is a bug I would suggest that this should be fixed >>> immediately. > >> What is the observed behavior of javax.comm on timeout? Are you sure it >> didn't just disable timeouts by default? > > I'm not sure. Unfortunately, I've never gotten javax.comm to work > under Windows and I don't have access to any other platform at this time. I > assume that you've used javax.comm before, so I encourage you to try it on > your end. Whatever they did, I really don't think that Sun would have > violated the InputStream specification by returning -1 on timeout. As the > BufferedReader.readLine() example shows, doing so triggers a lot of bugs. > I've actually never used the Sun implementation. RXTX and CommAPI have very different origins that overlap with Kevin Hester's "JCL" patch to bring them together. The rest has been done from the docs. Default settings have always been a source of confusion which is why I ask. Disabled timeouts/thresholds would behave like you expect. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue May 19 20:30:22 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 19 May 2009 22:30:22 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> <4A135ED4.3090608@bbs.darktech.org> Message-ID: <4A136B3E.7010704@bbs.darktech.org> Trent Jarvi wrote: > What is the observed behavior of javax.comm on timeout? Are you sure > it didn't just disable timeouts by default? Can someone who has used javax.comm please investigate this and let us know? Thanks, Gili From Steffen.DETTMER at ingenico.com Wed May 20 02:30:08 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 20 May 2009 10:30:08 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A131674.6000906@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> Message-ID: <20090520083008.GH17036@elberon.bln.de.ingenico.com> * cowwoc wrote on Tue, May 19, 2009 at 16:28 -0400: > Guys, I am feeling very frustrated with this whole discussion. (Me too, but probably for different reason :-)) > 1) There is no doubt that the current implementation breaks the > InputStream API. (which must happen, because InputStream as defined is less usable) > A return value of -1 is already mapped to end-of-stream. For > this reason, you *cannot* map the same value to a timeout. This > is basic design-by-contract! Currently (actually we are still using RXTX-2.1-7 which surely isn't the latest version :)), in case of timeout read(byte[]) returns 0. We have a wrapper implementation (which because of some rxtx timeout precision issues) might be a few lines more than needed but provides timeout precision typical better than 100ms (for us, this is sufficient). I wrote about it here some years ago. So it's possible to work with rxtx even with InputStream. Not very comfortable thanks for InputStream, but it works. Java developers expect InputStream (with its limitations). I was told this several times. May the java and javax APIs suck or not, but it is what most java developers are used to use, expect and what we live with in so many other areas, too. > 2) RXTX's implementation does not match javax.comm 100%. There > are plenty of situations where the two implementations diverge. > I am frustrated that people want to simultaneously freeze the > APIs and fix issues that *cannot* be fixed purely in the > implementation layer. As already written, I think a `real complete exhaustive fix' isn't possible or desired here for various reasons. The current way works well and complies to java stuff as much as possible (the differences are enforced logically and the InputStream specification IMHO is simply wrong). Now why change, requiring people to redevelop their applications or wrappers? Why not alternatively publish one of those wrappers (yours? :-)) under a public license and/or add it to rxtx allowing people that want exceptions allowing them to use configurable exceptions (for example)? > 3) "Premature optimization is the root of all evil" and yet I > see people complaining that exception handling costs 13 usec. > Java places emphasizes correctness above performance. If you > don't get that you shouldn't be coding in Java. In general, also `oversimplification is a root of evil' and IMHO nice examples can be found in Java APIs, but this is the way `everyone' goes. Raping exceptions as return codes IMHO is not a performance problem but a design problem (in a non-RAII-aware language which is not allowing ensured resource cleanups by guaranteed destructors this is a real big problem, IMHO). I don't understand the discussion. We have a read returning number of bytes read. We have situations where no byte is read. Now the API doesn't tell that in this case zero should be returned, but I think this is so damn obvious, isn't it?? > > A time out in a serial communication is almost always to be > > excepted since it is used to deal with real, live hardware > > outside the computer > > I disagree. Some application-level protocols don't use timeouts > at all. Why would your argument be true for serial connections > but not sockets? In general, everything has (or should have) timeouts /or/ be under control of something. Technically, the latter may require use `timeouts in a loop' (some polling). TCP has timeouts, for instance retransmission timeouts. Situations were no timeouts are defined in TCP (was it e.g. FIN_WAIT?) in the past lead to issues. On real OSes there are also UDP sockets, UNIX Domain Sockets and whatever else - and all of them and serial ports can accessed via one and the same API and select'd at the same time: timeout supported is simply built-in. For complex protcols, like TCP, all the heaps of defined timeouts might not be as visible as for serial case, where typical applications handle details themself, but they exist. > The classic IO api is synchronous whereas NIO channels are > asynchronous. Trying to retrofit timeouts on top of the old > APIs will never be as clean as using NIO which is designed > specifically for this purpose. I think classic is BSD socket API, which IMHO looks like a natural evolution of classic unix APIs. Works also for serial and everything (at least on unix and cygwin). I think Java people didn't saw the big picture and tried to simplify but oversimplified, assuming, InputStream could be used for all types of communication. Actually, it even can, but not alone (usually, you additionally need OutputStream and some ioctl). Now of course it was nice and sexy to critise the non-type-safe ioctl and select and to drop it - but this of course is no solution. Just ignoring the difficulties rarely helps. NIO is a bit more BSD socket API style, a step into the direction where everything comes from. Next version might take another step and reach the goal. Who knows. As far as I know none of the issues that lead to NIO (mostly performance and scalability) apply to rxtx. The only thing that seems to appy is that some buggy Javadoc tells InputStream would be blocking, available has no timeout, write timeouts are also not supported - and read(byte[]) never returns 0. Which quickly, easily and straightforward `fixes' the issues. That is what rxtx did. Isn't this fine? oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From m.j.tandy at warwick.ac.uk Wed May 20 03:01:51 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 20 May 2009 10:01:51 +0100 Subject: [Rxtx] InputStream timeouts In-Reply-To: <302aa0340905200201r912d9d0m6c9e1e41e049f1df@mail.gmail.com> References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> <302aa0340905200201r912d9d0m6c9e1e41e049f1df@mail.gmail.com> Message-ID: <302aa0340905200201t13a31a4bq30f60042c50fde63@mail.gmail.com> > 2) Violating the superclass specification can introduce an untold number > of bugs. For example, I spent hours trying to figure out why > BufferedReader.readLine() was returning null while the connection was > still open. We're discussing what the read() method does on timeout - but isn't the failure of BufferedReader.readLine caused by read(byte[] b, int off, int len) returning '0 bytes read' - not caused by what the read() method does on timeout? I mean, when I run the code below (Java 1.6.0_13-b03 / Sun JDK 6) the output is: Attempting to read a line... program called inputstream's read(byte[] b, int off, int len) java.io.IOException: Underlying input stream returned zero bytes ? ? ? ?at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) ? ? ? ?at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) ? ? ? ?at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) ? ? ? ?at java.io.InputStreamReader.read(InputStreamReader.java:167) ? ? ? ?at java.io.BufferedReader.fill(BufferedReader.java:136) ? ? ? ?at java.io.BufferedReader.readLine(BufferedReader.java:299) ? ? ? ?at java.io.BufferedReader.readLine(BufferedReader.java:362) ? ? ? ?at inputstreamtest.Main.main(Main.java:14) And if I look at the source code for StreamDecoder.java [1] I see the following lines: ?283 ? ? ? ? ? ? ? int n = in.read(bb.array(), bb.arrayOffset() + pos, rem); ?284 ? ? ? ? ? ? ? if (n < 0) ?285 ? ? ? ? ? ? ? ? ? return n; ?286 ? ? ? ? ? ? ? if (n == 0) ?287 ? ? ? ? ? ? ? ? ? throw new IOException("Underlying input stream returned zero bytes"); Which kind of makes sense, because the javadoc for read(byte[] b, int off, int len) [2] does explicitly say that "If len is zero, then no bytes are read and 0 is returned; otherwise, there is an attempt to read at least one byte. If no byte is available because the stream is at end of file, the value -1 is returned; otherwise, at least one byte is read and stored into b." Is this the problem that you encountered? Michael [1] http://www.docjar.com/html/api/sun/nio/cs/StreamDecoder.java.html [2] http://java.sun.com/javase/6/docs/api/java/io/InputStream.html#read(byte[],%20int,%20int) // CODE BEGINS HERE package inputstreamtest; import java.io.BufferedReader; import java.io.IOException; import java.io.InputStream; import java.io.InputStreamReader; public class Main { ? ?public static void main(String[] args) { ? ? ? ?BufferedReader in = new BufferedReader(new InputStreamReader(new FakeInputStream())); ? ? ? ?System.out.println("Attempting to read a line..."); ? ? ? ?try { ? ? ? ? ? ?in.readLine(); ? ? ? ?} catch (IOException e) { ? ? ? ? ? ?e.printStackTrace(); ? ? ? ?} ? ?} ? ?private static class FakeInputStream extends InputStream { ? ? ? ?@Override ? ? ? ?public int read(byte[] b, int off, int len) { ? ? ? ? ? ?System.out.println("program called inputstream's read(byte[] b, int off, int len)"); ? ? ? ? ? ?return 0; ? ? ? ?} ? ? ? ?@Override ? ? ? ?public int read() throws IOException { ? ? ? ? ? ?System.out.println("program called inputstream's read()"); ? ? ? ? ? ?return -1; ? ? ? ?} ? ?} } From Steffen.DETTMER at ingenico.com Wed May 20 03:16:20 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 20 May 2009 11:16:20 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> <20090519083335.GZ17036@elberon.bln.de.ingenico.com> <20090519191025.GF17036@elberon.bln.de.ingenico.com> Message-ID: <20090520091620.GI17036@elberon.bln.de.ingenico.com> * Trent Jarvi wrote on Tue, May 19, 2009 at 18:38 -0600: > >I think neither timeout nor framing errors are end of stream (end > >of file) but only `remote DTR drop' is. I'm not sure (and always > >confuse) to which input line its maps and whether it is hi or lo > >active... > > There really is an end of input in termios that would match up > fairly close in theory. The problem is it isnt really used as > far as I know. > > termois.c_cc[VEOF] - the end of input character. I assume it > is control-d. If you have a terminal open, try typing it into > the shell prompt :) Ahh yes, this way it was! (what means `logged out' and why my modem has no carrier?! :)) With a null modem cable and a C++ implementation I tried it and found that you are right, it is working with ^D (but not with DTR as I claimed), thanks for the correction. In `stty raw' ^D is 0x04 but after `stty sane' ^D works as end of input character, as you said. select(2) tells ready for read and read(2) return 0 bytes, which means EOF :-) (Well, in strict pure theory I think this could be considered a property of the terminal line discipline canonical mode, which IMHO could be considered a protocol property) BTW, is someone using this EOF in general? Our C++ implementation supports both it seems it (EOF detection) was never used. I guess it depends on the domain someone is working in? I could imagine that some micro controller control interfaces use that? oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed May 20 03:32:00 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 20 May 2009 11:32:00 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> <20090519083335.GZ17036@elberon.bln.de.ingenico.com> <20090519191025.GF17036@elberon.bln.de.ingenico.com> Message-ID: <20090520093200.GK17036@elberon.bln.de.ingenico.com> ps. our java implementation using RXTX-2.1-7 (surely very old) does not detect the ^D in `stty sane' mode. also, just BTW, about the IOException interruption discussion. When I aborted the java command line test program by ^C, I got IOException: java.io.IOException: Interrupted system call in readArray which IMHO shows that Kusti is right. The code not detecting EOF is similar to: port_.enableReceiveTimeout(intTimeout); bytesRead = port_.getInputStream().read( buffer, totalBytesRead, bytesRequested ); switch (bytesRead) { case -1: readClosedByPeer_ = true; break; case 0: // log interchar timeout if (totalBytesRead > 0) { rs232Logger_.finest( "Intercharacter timeout (" + getByteReadTimeout() + " ms) while reading, might be Ok. Returning " + totalBytesRead + " bytes read so far" ); } if (!ENABLE_RECEIVE_TIMEOUT_PRECISION_LOGGING) { break; } So actually I don't know if readClosedByPeer ever worked (we don't use it anyway I think). oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Wed May 20 03:57:30 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 12:57:30 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <302aa0340905200201t13a31a4bq30f60042c50fde63@mail.gmail.com> Message-ID: > From: Michael Tandy > And if I look at the source code for StreamDecoder.java [1] I see the > following lines: > ?283 ? ? ? ? ? ? ? int n = in.read(bb.array(), bb.arrayOffset() + pos, rem); > ?284 ? ? ? ? ? ? ? if (n < 0) > ?285 ? ? ? ? ? ? ? ? ? return n; > ?286 ? ? ? ? ? ? ? if (n == 0) > ?287 ? ? ? ? ? ? ? ? ? throw new IOException("Underlying input stream > returned zero bytes"); > > Which kind of makes sense, because the javadoc for read(byte[] b, int > off, int len) [2] does explicitly say that "If len is zero, then no > bytes are read and 0 is returned; otherwise, there is an attempt to > read at least one byte. If no byte is available because the stream is > at end of file, the value -1 is returned; otherwise, at least one byte > is read and stored into b." Not realy relevant for the discussion but out of curiosity I had peek at the code you quoted and just a few lines above we see: 278 int lim = bb.limit(); 279 int pos = bb.position(); 280 assert (pos <= lim); 281 int rem = (pos <= lim ? lim - pos : 0); 282 assert rem > 0; If asserts are disabled (the default IIRC) then 'rem' could be 0 in which case throwing exception on line 287 is not correct in that it is legal for read(byte[]) to return under that circumstance. Of course it maybe that the design of StreamDecoder otherwise guarantees that lim > pos but this just shows how difficult it is to be logically consistent all the time. Further browsing the StreamDecoder and CharsetDecorder classes it seems, at least superficially, that nothing has been gained by checking and throwing an exception, the rest of code would have worked correctly even if the the read on line 283 would return 0. All code that I've ever written have handled read(byte[]) returning 0 correctly (touch wood!) taking it on it's stride. Why not, you need to prepare for read to return less than what you asked so it naturally falls to handle the case of 0 also. From Kustaa.Nyholm at planmeca.com Wed May 20 04:06:12 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 13:06:12 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090520083008.GH17036@elberon.bln.de.ingenico.com> Message-ID: > From: Steffen DETTMER > >> 1) There is no doubt that the current implementation breaks the >> InputStream API. > (which must happen, because InputStream as defined is less usable) > Exactly. > Now why change, requiring people to redevelop their applications > or wrappers? Why not alternatively publish one of those wrappers > (yours? :-)) under a public license and/or add it to rxtx > allowing people that want exceptions allowing them to use > configurable exceptions (for example)? > Hear,hear, agree whole heartedly! > > I don't understand the discussion. We have a read returning > number of bytes read. We have situations where no byte is read. > Now the API doesn't tell that in this case zero should be > returned, but I think this is so damn obvious, isn't it?? To me it is soooooo obvious. > > The only thing that seems to appy is that some buggy Javadoc > tells InputStream would be blocking, available has no timeout, > write timeouts are also not supported - and read(byte[]) never > returns 0. Which quickly, easily and straightforward `fixes' the > issues. That is what rxtx did. Isn't this fine? It is fine. It ain't broken, don't fix it. This is mainly a documentation issue. When the map and scenery disagree trust the scenery. Thanks Steffen for summing it up so nicely! cheers Kusti From cowwoc at bbs.darktech.org Wed May 20 04:39:31 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 06:39:31 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090520083008.GH17036@elberon.bln.de.ingenico.com> References: <4A131674.6000906@bbs.darktech.org> <20090520083008.GH17036@elberon.bln.de.ingenico.com> Message-ID: <4A13DDE3.8070703@bbs.darktech.org> Steffen DETTMER wrote: > * cowwoc wrote on Tue, May 19, 2009 at 16:28 -0400: >> Guys, I am feeling very frustrated with this whole discussion. > > (Me too, but probably for different reason :-)) > >> 1) There is no doubt that the current implementation breaks the >> InputStream API. > > (which must happen, because InputStream as defined is less usable) Not true. Either we follow the InputSteam specification or we define our own interface. Breaking the specification in this way will trigger unpredictable bugs. > Currently (actually we are still using RXTX-2.1-7 which surely > isn't the latest version :)), in case of timeout read(byte[]) > returns 0. > > I don't understand the discussion. We have a read returning > number of bytes read. We have situations where no byte is read. > Now the API doesn't tell that in this case zero should be > returned, but I think this is so damn obvious, isn't it?? Actually, the Javadoc for read(byte[]) says that at least one byte must be read: "If the length of b is zero, then no bytes are read and 0 is returned; otherwise, there is an attempt to read at least one byte. If no byte is available because the stream is at the end of the file, the value -1 is returned; otherwise, at least one byte is read and stored into b." > In general, everything has (or should have) timeouts /or/ be > under control of something. Technically, the latter may > require use `timeouts in a loop' (some polling). TCP has > timeouts, for instance retransmission timeouts. Situations were > no timeouts are defined in TCP (was it e.g. FIN_WAIT?) in the > past lead to issues. On real OSes there are also UDP sockets, > UNIX Domain Sockets and whatever else - and all of them and > serial ports can accessed via one and the same API and select'd > at the same time: timeout supported is simply built-in. > For complex protcols, like TCP, all the heaps of defined timeouts > might not be as visible as for serial case, where typical > applications handle details themself, but they exist. Fair enough, but "timeouts in a loop" -- using available() -- don't break the InputStream specification. > NIO is a bit more BSD socket API style, a step into the direction > where everything comes from. Next version might take another step > and reach the goal. Who knows. As far as I know none of the > issues that lead to NIO (mostly performance and scalability) > apply to rxtx. NIO allows you to select() on a channel with a timeout, which is the point of contention. > The only thing that seems to appy is that some buggy Javadoc > tells InputStream would be blocking, available has no timeout, > write timeouts are also not supported - and read(byte[]) never > returns 0. Which quickly, easily and straightforward `fixes' the > issues. That is what rxtx did. Isn't this fine? I'm not sure I understand. I get that you dislike that InputStream doesn't provide facilities for non-blocking reads but that is just life. You're supposed to either create your own interface or use NIO for that. In my view, breaking the superclass contract is always worse than inconveniencing yourself. Gili From cowwoc at bbs.darktech.org Wed May 20 04:41:14 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 06:41:14 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <302aa0340905200201t13a31a4bq30f60042c50fde63@mail.gmail.com> References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> <302aa0340905200201r912d9d0m6c9e1e41e049f1df@mail.gmail.com> <302aa0340905200201t13a31a4bq30f60042c50fde63@mail.gmail.com> Message-ID: <4A13DE4A.70704@bbs.darktech.org> Yes. Gili Michael Tandy wrote: >> 2) Violating the superclass specification can introduce an untold number >> of bugs. For example, I spent hours trying to figure out why >> BufferedReader.readLine() was returning null while the connection was >> still open. > > We're discussing what the read() method does on timeout - but isn't > the failure of BufferedReader.readLine caused by read(byte[] b, int > off, int len) returning '0 bytes read' - not caused by what the read() > method does on timeout? > > I mean, when I run the code below (Java 1.6.0_13-b03 / Sun JDK 6) the output is: > > Attempting to read a line... > program called inputstream's read(byte[] b, int off, int len) > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > at inputstreamtest.Main.main(Main.java:14) > > And if I look at the source code for StreamDecoder.java [1] I see the > following lines: > 283 int n = in.read(bb.array(), bb.arrayOffset() + pos, rem); > 284 if (n < 0) > 285 return n; > 286 if (n == 0) > 287 throw new IOException("Underlying input stream > returned zero bytes"); > > Which kind of makes sense, because the javadoc for read(byte[] b, int > off, int len) [2] does explicitly say that "If len is zero, then no > bytes are read and 0 is returned; otherwise, there is an attempt to > read at least one byte. If no byte is available because the stream is > at end of file, the value -1 is returned; otherwise, at least one byte > is read and stored into b." > > Is this the problem that you encountered? > > Michael > > [1] http://www.docjar.com/html/api/sun/nio/cs/StreamDecoder.java.html > [2] http://java.sun.com/javase/6/docs/api/java/io/InputStream.html#read(byte[],%20int,%20int) > > > // CODE BEGINS HERE > package inputstreamtest; > > import java.io.BufferedReader; > import java.io.IOException; > import java.io.InputStream; > import java.io.InputStreamReader; > > public class Main { > > public static void main(String[] args) { > BufferedReader in = new BufferedReader(new > InputStreamReader(new FakeInputStream())); > System.out.println("Attempting to read a line..."); > try { > in.readLine(); > } catch (IOException e) { > e.printStackTrace(); > } > } > > private static class FakeInputStream extends InputStream { > @Override > public int read(byte[] b, int off, int len) { > System.out.println("program called inputstream's > read(byte[] b, int off, int len)"); > return 0; > } > > @Override > public int read() throws IOException { > System.out.println("program called inputstream's read()"); > return -1; > } > } > > } > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From cowwoc at bbs.darktech.org Wed May 20 04:45:25 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 06:45:25 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <4A13DF45.7030305@bbs.darktech.org> Kustaa Nyholm wrote: > It is fine. It ain't broken, don't fix it. This is mainly > a documentation issue. When the map and scenery disagree trust > the scenery. This isn't "documentation". It's a specification. The core Java APIs implement it perfectly and expect it to be followed 100% of the time. It is impossible to change it this late in the game. Gili From Kustaa.Nyholm at planmeca.com Wed May 20 06:03:15 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 15:03:15 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A131674.6000906@bbs.darktech.org> Message-ID: > > Guys, I am feeling very frustrated with this whole discussion. I feel your pain as I'm frustrated, not by the discussion which has been conducted in a gentlemanly maner and has entertained me quite a lot, but by people trying to fix what ain't broken. > > 1) There is no doubt that the current implementation breaks the > InputStream API. Well, this is like saying my car is broken because a mouse ate the registration paper (honestly, that happened last winter). There is only a very minor discrepancy between what a few document sentences says and what *useful and practical* functionality the current rxtx/javacomm provides. > A return value of -1 is already mapped to > end-of-stream. For this reason, you *cannot* map the same value to a > timeout. This is basic design-by-contract! I thought we already agreed (talking about read(byte[])) 0 should be returned and AFAIK *is* returned. And this matches the javadoc for CommPort.getInputStream() which says that it return a kind of InputStream where read operations blocks until a timeout occurs OR until any data is available. So it can return even when no data is available. And in that case 0 seems like an appropriate return value. It bends the rules of InputStream a bit, but this is by design, not error. Now, if read() returns -1 in case of timeout this is a dilemma as it does allow differentiation between EOF (whatever it means for serial stream) and timeout. However the 'golden standard', the stream object that javacomm.SerialPort.getInputStream().read(), returns in case of timeout is -1, at least on Windows (just tested it). And we should not brake this compatibility. > > 2) RXTX's implementation does not match javax.comm 100%. > So? Why make it match even less? Most people want compatibility and usability, not semantic / logical correctness at least as far as something as small as serial port API is concerned. Go write your own wrapper if it bother you. > There are > plenty of situations where the two implementations diverge. If there are, please let us know, this is very useful information for any rxtx user so that they can avoid these pitfalls. > I am > frustrated that people want to simultaneously freeze the APIs and fix > issues that *cannot* be fixed purely in the implementation layer. What issues you mean? Off hand I don't recall people asking for fixes that would match your description of "that *cannot* be fixed purely in the implementation layer". Personally, all I've ever wanted from javacomm and rxtx was to be able to access the serial port from Java in platform neutral fashion that allows my code to run on the three major platforms Mac OS X, Linux and Windows. And rxtx delivers just that. > > 3) "Premature optimization is the root of all evil" and yet I see people > complaining that exception handling costs 13 usec. I'm sure you understood that 13 usec was not the point. The point is that exception handling concept has been designed to handle exceptional case which are rare and thus performance of the code when an exception is thrown can be slow. The penalty is not specified but includes creating a new object or several (stack trace) and frequently warned about. Like I said, and I'm sure you understood, at 9600 baud this penalty is not an issue, but in a slower machine (mine was, as stated 2.8 GHz/4GB/1066MHz Core 2 Duo), or different JVM, or JIT not happening (BTW exception handling disturbs JIT) it could be a decade slower. So make it 100 usec and raise baud rate to 1 MBps now merely throwing the exception takes ten times longer than a one character timeout. Many protocols I have programmed have used pauses of less than that to frame messages. IMO it would be serious mistake to use exceptions to handle timeouts. Ever wondered why EOF is signaled with -1 and not an exception... > Java places > emphasizes correctness above performance. If you don't get that you > shouldn't be coding in Java. This is not what I would call parliamentary language. I won't reply. > > More specific replies below... > >> Throwing InterruptedIOException from InputStream.read() is just as >> big sin as it breaks the contract of InterruptedIOException , which >> says that the *thread* that was performing the IO was interrupted. > > A thread getting interrupted is not the same as Thread.interrupt(). Oh yeah? Really? In the context it was used I beg to differ. > My interpretation is that interrupting the operation due to a timeout is a > perfectly legal form of "thread interruption". Even with respect to > Thread.interrupt(), you can't interrupt a thread, only the work it is > executing. > >> Coneceptually I feel throwing an exception is a big sin in a situation >> which is not an error. > > Exceptions refer to "exceptional circumstances" which is not the same > as "errors". By that I mean that the "normally" the method returns > 0-255, but exceptional cases such as timeouts are perfectly legal. But timeout with SerialPort usually is not an exceptional case. But I guess you are fixed to your idea that it is. The important thing however is that it is not for me or you to decide and thus it is not for the API to dictate this. > >> A time out in a serial communication is >> almost always to be excepted since it is used to deal with real, live >> hardware outside the computer > > I disagree. Some application-level protocols don't use timeouts at > all. > Why would your argument be true for serial connections but not sockets? What Sockets and application level protocols have got to do with reading a SerialPort/RS232 port and it's timeouts? > >> So you are advocating adding a new class SerialPortChannel and >> a new method SerialPort.getSerialPortChannel() ? >> >> That would be acceptable in that it would not brake existing code but >> totally unnecessary in my view. I suspect most people turn to rxtx >> as a replacement for javacomm and are only interested in getting the >> job done. And the current API does this with very nicely. I think >> we all have better use for our time than to re-invent a serial port >> API. > > The classic IO api is synchronous whereas NIO channels are > asynchronous. Trying to retrofit timeouts on top of the old APIs will > never be as clean as using NIO which is designed specifically for this > purpose. > You maybe right, but the cure is worse than the disease and the first rule of a good doctor is to "do no harm". What you are concerned about is some semantic details what most of us are concerned with is getting the job done. Here are some more thoughts on using exceptions in case you can be bothered. Quoting from Sun's exception handling tutorial: http://java.sun.com/docs/books/tutorial/essential/exceptions/throwing.html "An Exception indicates that a problem occurred" Now, a timeout, to me, is not a problem, but very often an essential part of the communication protocol. Of course for some in some situations it maybe a problem, but that is not for the (communication) API designer to decide or dictate. To me this spells that timeouts should not throw an exception. Also from the same document: "Here's the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception." Following this guideline would dictate that timeout exception should be a checked exception (because surely almost universally the programmer who enables timeouts (disable by default, remember) can and will handle the timeouts in some reasonable way. *Adding a checked exception toInputStream.reads is not possible.* Again this speaks against throwing an exception in case of timeouts. More in the same vein: http://developer.apple.com/documentation/Performance/Conceptual/CodeSpeed/Ar ticles/TuningJavaCode.html#//apple_ref/doc/uid/TP40002329-DontLinkElementID_ 4 "Exception handling in Java is very slow. ... use exceptions only for truly exceptional cases. Do not use exceptions to indicate simple errors from which your code could otherwise recover. Instead, use them only to indicate abnormal conditions that your code does not know how to handle." cheers Kusti From Kustaa.Nyholm at planmeca.com Wed May 20 06:20:34 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 15:20:34 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A13DDE3.8070703@bbs.darktech.org> Message-ID: > > Not true. Either we follow the InputSteam specification or we define > our own interface. Breaking the specification in this way will trigger > unpredictable bugs. Well bugs are by their very nature unpredictable, what? But seriously who are you to dictate "high road or low road"? Who says we (whoever that 'we' are) must either follow 100% or define our own? If 'we' want to take a middle road we surely can. And I'm all for it. Pursuing 100% clean designs is a fruitless goal and I've got better things to do than keep updating my code base to track an ever changing API in pursuit of an unattainable internal and external purity and correctness. > > Fair enough, but "timeouts in a loop" -- using available() -- don't > break the InputStream specification. So why not use it? If you do not touch the enableTimeout() and enableThreshold() methods the SerialPort.InputStream fulfills the contract to the letter. And if you touch them, it fulfills the commitment that creators of the original API made. > You're supposed to either create your own interface or use NIO for that. > In my view, breaking the superclass contract is always worse than > inconveniencing yourself. Why don't you provide a proof of concept framework of classes and interfaces that are internally and externally consistent for us to scrutinize? I bet it will contain one or two compromises and bending of the rules or be totally out of tune what people need or want to use. cheers Kusti From Steffen.DETTMER at ingenico.com Wed May 20 07:23:40 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 20 May 2009 15:23:40 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A13DDE3.8070703@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> <20090520083008.GH17036@elberon.bln.de.ingenico.com> <4A13DDE3.8070703@bbs.darktech.org> Message-ID: <20090520132339.GB27170@elberon.bln.de.ingenico.com> * cowwoc wrote on Wed, May 20, 2009 at 06:39 -0400: > >>1) There is no doubt that the current implementation breaks the > >>InputStream API. > > > >(which must happen, because InputStream as defined is less usable) > > Not true. Either we follow the InputSteam specification or we define > our own interface. Breaking the specification in this way will trigger > unpredictable bugs. First, I disagree that it is specification because it actually is documentation. A specification would also need to specify how overloaded methods are allowed to change without violating the specification. If javadoc in general would be no documentation but specification obviously no overloaded method could specialise or change any behavior, because as soon as documentation of an overloaded would be needed, it would violate base class specification, in short, no new specification (documentation) could be allowed in any subclass. Theoretically this could be a point (an option to develop a language) but I think it makes not much sense in practice. Also, it often happens that even in specifications there are obvious issues, as soon as everyone does the obvious thing, instead of changing all implementations, the specification is fixed. Or left as it is :) Of course we define an own interface by deriving (implementing) InputStream because specifics will happen. For instance specialised exceptions may be thrown in special new situations not documented (specified) by InputStream. This is what OO is for I think. :) > Actually, the Javadoc for read(byte[]) says that at least one > byte must be read: "If the length of b is zero, then no bytes > are read and 0 is returned; otherwise, there is an attempt to > read at least one byte. If no byte is available because the > stream is at the end of the file, the value -1 is returned; > otherwise, at least one byte is read and stored into b." Strictly speaking, at least for me with my limited foreign language English knowledge, it does not tell what happens if an attempt to read at least one byte was done, no byte was available, the stream is NOT at the end of the file, but still no byte was read. I would accept the point that, strictly speaking, InputStream unconditionally forbids any timeout support (except polling available(), which at least sucks). This actually was my initial point. This prohibition makes no sense and probably was just done by accident (otherwise, docu should tell this) and also is violated if throwing exceptions and also is violated by Java stuff itself. > Fair enough, but "timeouts in a loop" -- using available() -- > don't break the InputStream specification. Yes, and somewhere probably there is some guy who defined InputStream as an Aprils Fool Joke and now cannot sleep because laughing about all those people that poll available() all the time (no delay to gain response time) wasting all CPU resources :-) Anyway, since years InputStream is used and I don't think we can do anything against. I also don't like it, but that's life. If you want a nice language use C++ or Ruby or so ;) SCNR. > >NIO is a bit more BSD socket API style, a step into the direction > >where everything comes from. Next version might take another step > >and reach the goal. Who knows. As far as I know none of the > >issues that lead to NIO (mostly performance and scalability) > >apply to rxtx. > > NIO allows you to select() on a channel with a timeout, which > is the point of contention. Yes, but not if the channel is some InputStream like STDIN, right? Also, as far as I know, you cannot select on own things. So wouldn't work for serial lines or protocols. I think you cannot implement TCP via PPP reasonable and efficiently in (pure) Java, even with NIO as far as I know this is not possible. But there are many things in Java that you cannot implement in Java (even String!). A pitty but otherwise things would be horrible slow. > I'm not sure I understand. I get that you dislike that > InputStream doesn't provide facilities for non-blocking reads > but that is just life. You're supposed to either create your > own interface or use NIO for that. In my view, breaking the > superclass contract is always worse than inconveniencing > yourself. I think, when we would discuss NIO, we would also quickly find sufficient issues with it (I think we had this discussion already) and that we do not (really :)) break the superclass contract (of InputStream). We just add possibility to support timeout (by new method setReceiveTimeout() and overloaded read()). :-) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed May 20 07:40:03 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 20 May 2009 15:40:03 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> Message-ID: <20090520134002.GC27170@elberon.bln.de.ingenico.com> (OT) * Kustaa Nyholm wrote on Wed, May 20, 2009 at 15:03 +0300: > Ever wondered why EOF is signaled with -1 and not an exception... Yeah... I always wonder why Java has so many issues that were already discussed and solved since ages in POSIX or ANSI-C or C++ /before/ java was started. On POSIX reads -1 is error. You call some select(2) before. If select tells ready-for-read and you read EOF, read returns 0 bytes. This is at least a bit intuitive - and seems to work in all cases. Seeing a file descriptor like a class IMHO works. read(fd, ..) could be understood as fd.read(). When looking how great in overall this works I feel deep respect for all the people who invented that :) > > Java places emphasizes correctness above performance. This is definitely wrong. Much of Java Core Tech is uglyDirtyNasty because of performance. For instance you cannot overload String (reasonable). Operator overloading is not possible except for String.operator+ (concatenation). Implicite conversion is possible by Object().toString() but nowhere else. You cannot implement a toLong() and have it be called implicitely. String automatically uses StringBuffer for operations, again a hack you have no chance to copy or influence. You cannot pass scalars like long by reference, you are force to pass them by value. You cannot pass Objects by value, you are forced to pass them by reference. Except your object is e.g. a Long, then it is passed by value. You cannot implement any of that in Java itself. It is Mr. JVM in person :) who knows those hacks and how to workaround / pass by. Also great is Object.clone(). Works without overloading. How does Object.clone() know the members of the child class? Because it knows the structure and hacks it to match. Same for serialisation and deserialisation. Object construction. Why can an Object call a method overloaded in a child class in its constructor? Interesting is what happens: the child class is already `half constructed', i.e. working except member initialisation and its constructor was not run. But a method can be invoked. This is not clean this sucks but anyway. We could continue this quite some time (Inner Class hacks, Generics hacks, forced GC, no RAII support would be next) :-) Honestly, a student would not pass a university test with so much hacking (I hope ;)). oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From michael.erskine at ketech.com Wed May 20 07:45:13 2009 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 20 May 2009 14:45:13 +0100 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0D6BA5.8020209@bbs.darktech.org> References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <06BA3262D918014F9183B66425D5A8D463C3C2E90A@no-sv-03.ketech.local> I wander in to find a gazillion posts about whether RXTX is breaking some rule or other. I don't have time to read and argue the toss over which way of doing something may be more correct. As far as I'm concerned (and, I venture, the other developers in industry) whatever RXTX does _IS_ the right thing. I don't fancy trying to justify the costs that would be incurred in the respecifying, rewriting, and retesting of an absolute ton of SIL2 software. Please, let's not screw things up. Regards, Michael Erskine. From Kustaa.Nyholm at planmeca.com Wed May 20 07:58:12 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 16:58:12 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090520134002.GC27170@elberon.bln.de.ingenico.com> Message-ID: Just to clarify Steffen's mail, this was not my sentence: >>> Java places emphasizes correctness above performance. to which he responded: > > This is definitely wrong. Much of Java Core Tech is > uglyDirtyNasty because of performance. > > Honestly, a student would not pass a university test with so much > hacking (I hope ;)). > and with which I agree. cheers Kusti From Kustaa.Nyholm at planmeca.com Wed May 20 08:13:54 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 17:13:54 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <06BA3262D918014F9183B66425D5A8D463C3C2E90A@no-sv-03.ketech.local> Message-ID: Michael Erskine: > I wander in to find a gazillion posts about whether RXTX is breaking some rule > or other. I don't have time to read and argue the toss over which way of doing > something may be more correct. I've participated in the discussion just for that reason, trying to prevent anyone 'correcting' this API. > > As far as I'm concerned (and, I venture, the other developers in industry) > whatever RXTX does _IS_ the right thing. Indeed! > > I don't fancy trying to justify the costs that would be incurred in the > respecifying, rewriting, and retesting of an absolute ton of SIL2 software. > Hear, hear! > Please, let's not screw things up. Yeah, let's not screw this up. From cowwoc at bbs.darktech.org Wed May 20 08:40:11 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 10:40:11 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090520132339.GB27170@elberon.bln.de.ingenico.com> References: <4A131674.6000906@bbs.darktech.org> <20090520083008.GH17036@elberon.bln.de.ingenico.com> <4A13DDE3.8070703@bbs.darktech.org> <20090520132339.GB27170@elberon.bln.de.ingenico.com> Message-ID: <4A14164B.6040000@bbs.darktech.org> Steffen DETTMER wrote: > First, I disagree that it is specification because it actually is > documentation. A specification would also need to specify how > overloaded methods are allowed to change without violating the > specification. If javadoc in general would be no documentation > but specification obviously no overloaded method could specialise > or change any behavior, because as soon as documentation of an > overloaded would be needed, it would violate base class > specification, That is incorrect. Design by Contract allows subclasses to weaken preconditions, strengthen postconditions and strengthen invariants -- all without violating the superclass specification. > Also, it often happens that even in specifications there are > obvious issues, as soon as everyone does the obvious thing, > instead of changing all implementations, the specification is > fixed. Or left as it is :) As far as I know, this has never been done for core Java classes because doing so would break backwards compatibility. This is discussed at length in the Effective Java book. > Of course we define an own interface by deriving (implementing) > InputStream because specifics will happen. For instance > specialised exceptions may be thrown in special new situations > not documented (specified) by InputStream. This is what OO is for > I think. :) A subclass may not throw any new (checked) exceptions. Doing so would violating the superclass specification. You could always throw a subclass of IOException but that's about it. The reason this only applies to checked exceptions is that all methods throw RuntimeException by default. >> Actually, the Javadoc for read(byte[]) says that at least one >> byte must be read: "If the length of b is zero, then no bytes >> are read and 0 is returned; otherwise, there is an attempt to >> read at least one byte. If no byte is available because the >> stream is at the end of the file, the value -1 is returned; >> otherwise, at least one byte is read and stored into b." > > Strictly speaking, at least for me with my limited foreign > language English knowledge, it does not tell what happens if an > attempt to read at least one byte was done, no byte was > available, the stream is NOT at the end of the file, but still no > byte was read. The sentence above reads "This method blocks until input data is available, end of file is detected, or an exception is thrown." In other words, you must block. > I would accept the point that, strictly speaking, InputStream > unconditionally forbids any timeout support (except polling > available(), which at least sucks). > > This actually was my initial point. This prohibition makes no > sense and probably was just done by accident (otherwise, docu > should tell this) and also is violated if throwing exceptions and > also is violated by Java stuff itself. If a timeout could be said to be a new kind of end-of-stream (with the resulting behavior being absolutely identical) then using -1 might be fine. Unfortunately, this is not the case. End-of-stream indicates that the InputStream will never return bytes ever again. Timeouts violate this guarantee. With respect to exceptions, you are allowed to throw any subclass of IOException for the reasons mentioned in Design by Contract. >> Fair enough, but "timeouts in a loop" -- using available() -- >> don't break the InputStream specification. > > Yes, and somewhere probably there is some guy who defined > InputStream as an Aprils Fool Joke and now cannot sleep because > laughing about all those people that poll available() all the > time (no delay to gain response time) wasting all CPU resources > :-) InputStream works perfectly fine for synchronous reading. If you want asynchronous reading you are supposed to use NIO channels. >> NIO allows you to select() on a channel with a timeout, which >> is the point of contention. > Yes, but not if the channel is some InputStream like STDIN, > right? Also, as far as I know, you cannot select on own things. > So wouldn't work for serial lines or protocols. I don't understand what you mean. You can get a Channel for System.in using java.nio.channels.Channels. > I think you cannot implement TCP via PPP reasonable and > efficiently in (pure) Java, even with NIO as far as I know this > is not possible. But there are many things in Java that you > cannot implement in Java (even String!). You can find TCP/PPP implementations in Java on the web. You don't need them most of the time because the OS provides an implementation for free. > I think, when we would discuss NIO, we would also quickly find > sufficient issues with it (I think we had this discussion > already) and that we do not (really :)) break the superclass > contract (of InputStream). We just add possibility to support > timeout (by new method setReceiveTimeout() and overloaded read()). Again, I suggest you read up on Design by Contract. You will find out exactly why you are not allowed to overload the -1 return code in this way. Gili From cowwoc at bbs.darktech.org Wed May 20 08:46:08 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 10:46:08 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <06BA3262D918014F9183B66425D5A8D463C3C2E90A@no-sv-03.ketech.local> References: <4A0D6BA5.8020209@bbs.darktech.org> <06BA3262D918014F9183B66425D5A8D463C3C2E90A@no-sv-03.ketech.local> Message-ID: <4A1417B0.3040903@bbs.darktech.org> Michael, You have a choice to either break compatibility with old versions of RXTX or break compatibility with all other libraries in existence. Both options suck, but the latter involves breaking even more code. Right now you cannot safely pass RXTX's InputStream into any other library in existence. Gili Michael Erskine wrote: > I wander in to find a gazillion posts about whether RXTX is breaking some rule or other. I don't have time to read and argue the toss over which way of doing something may be more correct. > > As far as I'm concerned (and, I venture, the other developers in industry) whatever RXTX does _IS_ the right thing. > > I don't fancy trying to justify the costs that would be incurred in the respecifying, rewriting, and retesting of an absolute ton of SIL2 software. > > Please, let's not screw things up. > > Regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From johnny.luong at trustcommerce.com Wed May 20 09:55:03 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Wed, 20 May 2009 08:55:03 -0700 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> Message-ID: <4A1427D7.2020906@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Trent Jarvi wrote: | On Tue, 19 May 2009, cowwoc wrote: |>> A time out in a serial communication is |>> almost always to be excepted since it is used to deal with real, live |>> hardware outside the computer |> I disagree. Some application-level protocols don't use timeouts at all. |> Why would your argument be true for serial connections but not sockets? |> | | Hi Gili | | One fundamental difference between sockets, file io and RS232 | communication is that sockets and file systems provide error handling. | If a packet is lost, it is resent without the java API knowing about it. | | RS232 is actually an electrical signal standard. Serial communication | exposes a UART without any meaningful error handling and cludgy error | reporting. | | Given the above, ignoring timeouts is not really a valid rxtx level | option. We could have a new option/method that allows you to get an | InputStream or Channel that behaves as you wish. | | If we change the InputStream returned by getInputStream(), that would | be change in the API (version 3.0) that forks our userbase. | | So I guess my question is whether or not you are trying to change the | object returned by getInputStream or just looking for a means to get a | different object you would like to define be returned. | | The later is far easier to accommodate. | | -- | Trent Jarvi | tjarvi at qbang.org | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Trent, For sockets, I'm not so sure there is really any guarantees short of actually monitoring it externally. For example, write() in outputstream doesn't return any value whatsoever -- you might get an exception but in the worse case, it just tells you something bad happened and in the best case, you might be able to catch some implementation specific exception. ~ The same could apply to files too but the magnitude of failure there are significantly lower. But this is sort of a digression... My thinking is that we just sort of keep the interface so that we don't disrupt people who use the methods (our software actually polls from the serial port version of the InputStream/OutputStream as a side effect of the quirkyness involved with the timeout -- this is because the USB-serial thing we had to work with really sucks) but add an additional interface similar to what is SocketChannel and proceed from there. There is a lot of work involved in it though and as it has been pointed out by others, maybe most can live with the hacks involved in the current implementation. Best, Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoUJ9cACgkQnQTBLXttTeVYlQCfcvIHMh1W1kcna5vUtg20dWWK flMAn2WZk03PSgYT1KkHMLp8TlLRtcxn =YeMI -----END PGP SIGNATURE----- From michaeltandy at googlemail.com Wed May 20 09:57:36 2009 From: michaeltandy at googlemail.com (Michael Tandy) Date: Wed, 20 May 2009 16:57:36 +0100 Subject: [Rxtx] Rxtx native library loading In-Reply-To: References: <302aa0340905190733r4009e394v335b3ef47d84ffb5@mail.gmail.com> Message-ID: <302aa0340905200857v53642f58je6932c3315b8a30d@mail.gmail.com> There's also a bug in my code; it worked fine swapping between my Windows machine and my 64-bit Linux machine, but trying to run the 64-bit library on my 32-bit Linux laptop (obviously) doesn't work. So, it needs to detect more architectures and handle them more cleverly :) Still, if your next release will do that, I guess I don't have to fix my code :) Thanks Michael 2009/5/20 Trent Jarvi : > > Hi Michael, > > We will be putting a patch like yours in as soon as we release 2.2. ?The > release was going to be mothers day but I got caught up :) ?I hope to do it > next weekend. ?After that we will be looking at web installs which overlaps > with your solution. > > -- > Trent Jarvi > tjarvi at qbang.org > From cowwoc at bbs.darktech.org Wed May 20 10:04:32 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 12:04:32 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A1427D7.2020906@trustcommerce.com> References: <4A131674.6000906@bbs.darktech.org> <4A1427D7.2020906@trustcommerce.com> Message-ID: <4A142A10.1090302@bbs.darktech.org> Johnny Luong wrote: > My thinking is that we just sort of keep the interface so that we don't > disrupt people who use the methods (our software actually polls from the > serial port version of the InputStream/OutputStream as a side effect of > the quirkyness involved with the timeout -- this is because the > USB-serial thing we had to work with really sucks) but add an additional > interface similar to what is SocketChannel and proceed from there. We could also deprecate getInputStream() in favor of another method that returns a fixed implementation. This will allow existing code to keep on working while providing a migration route for RXTX 3.0. Gili From jerrypedersen at telus.net Wed May 20 10:10:00 2009 From: jerrypedersen at telus.net (Jerry Pedersen) Date: Wed, 20 May 2009 09:10:00 -0700 Subject: [Rxtx] 38400 Baud - UnsupportedCommOperationexception: Invalid Parameter Message-ID: <4A142B58.4050909@telus.net> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090520/0ac89fb9/attachment-0003.html From bill7007 at gmail.com Wed May 20 11:20:13 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Wed, 20 May 2009 13:20:13 -0400 Subject: [Rxtx] 38400 Baud - UnsupportedCommOperationexception: Invalid Parameter In-Reply-To: <4A142B58.4050909@telus.net> References: <4A142B58.4050909@telus.net> Message-ID: Hi Jerry, You might check out: [Rxtx] Baud rate fixes in 2.2pre2 breaks 38400 on some Linux devices It has a link to a patch on 2.2pre that got me around a similar problem. +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090520/046aa29d/attachment-0003.html From Kustaa.Nyholm at planmeca.com Wed May 20 12:23:41 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 21:23:41 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A1417B0.3040903@bbs.darktech.org> References: <4A0D6BA5.8020209@bbs.darktech.org> <06BA3262D918014F9183B66425D5A8D463C3C2E90A@no-sv-03.ketech.local>, <4A1417B0.3040903@bbs.darktech.org> Message-ID: <5D23E5B41156B646B2E1A7C2BBA916F317119151AF@SRVFIHKIEXB01.pmgroup.local> Gili wrote: >You have a choice to either break compatibility with old versions of >RXTX or break compatibility with all other libraries in existence. Both >options suck, but the latter involves breaking even more code. Or, the third option, leave it well alone! Keep it compatible existing code that is actually using rxtx instead of just worrying about it being correct to a T. Use it as the creators meant it to be used. Stop worrying about this. > Right now you cannot safely pass RXTX's InputStream into any other >library in existence. Now that is blatantly untrue. If timeouts are not enable you can pass it safely to any library. When timeouts are enabled *some* libraries will not work, some will. If you worry or encounter such a situation you can then do some wrapper magic. But for pete's sake, let us not disturb the happy life of rxtx users with well intentioned but misguided zealozy. I wonder too how often SerialPort input stream is passed to *any* library? I certainly haven't done that ever. The way I vision people are using serial port is to talk directly to it doing most if not all of the protocol handling with custom code, not with a library. If pass it (the input stream) to a library that chokes on read returning 0 it is rather your fault for not reading what the javadoc for SerialPort.getInputStream says! cheers Kusti From tjarvi at qbang.org Wed May 20 17:18:37 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 May 2009 17:18:37 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A142A10.1090302@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> <4A1427D7.2020906@trustcommerce.com> <4A142A10.1090302@bbs.darktech.org> Message-ID: On Wed, 20 May 2009, cowwoc wrote: > Johnny Luong wrote: >> My thinking is that we just sort of keep the interface so that we don't >> disrupt people who use the methods (our software actually polls from the >> serial port version of the InputStream/OutputStream as a side effect of >> the quirkyness involved with the timeout -- this is because the >> USB-serial thing we had to work with really sucks) but add an additional >> interface similar to what is SocketChannel and proceed from there. > > We could also deprecate getInputStream() in favor of another method > that returns a fixed implementation. This will allow existing code to > keep on working while providing a migration route for RXTX 3.0. > Hi Gili, Good. I think it is time to see the method and InputStream. From there, we can discuss options in 3.0. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Wed May 20 18:49:50 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 20:49:50 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> <4A1427D7.2020906@trustcommerce.com> <4A142A10.1090302@bbs.darktech.org> Message-ID: <4A14A52E.7080701@bbs.darktech.org> Trent Jarvi wrote: > Good. > > I think it is time to see the method and InputStream. From there, we > can discuss options in 3.0. I propose the following: 1) add "CommPortChannel getChannel()" 2) deprecate getInputStream() and enableReceiveTimeout() in favor of getChannel() 3) getChannel() will return a class that implements the same interfaces as SocketChannel. It will allow both blocking and non-blocking I/O operations. 4) In RXTX 3.0 getInputStream() will return an InputStream that always blocks on reads and the method will be undeprecated. Gili From tjarvi at qbang.org Wed May 20 19:27:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 May 2009 19:27:50 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A14A52E.7080701@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> <4A1427D7.2020906@trustcommerce.com> <4A142A10.1090302@bbs.darktech.org> <4A14A52E.7080701@bbs.darktech.org> Message-ID: On Wed, 20 May 2009, cowwoc wrote: > Trent Jarvi wrote: >> Good. >> >> I think it is time to see the method and InputStream. From there, we can >> discuss options in 3.0. > > I propose the following: > > 1) add "CommPortChannel getChannel()" > 2) deprecate getInputStream() and enableReceiveTimeout() in favor of > getChannel() > 3) getChannel() will return a class that implements the same interfaces as > SocketChannel. It will allow both blocking and non-blocking I/O operations. > 4) In RXTX 3.0 getInputStream() will return an InputStream that always blocks > on reads and the method will be undeprecated. > Hi Gili, RXTX 3.0 would be the soonest we would start any deprecation if it is agreed upon. So far, I don't think there is near enough buy in. But you can have getChannel now. If it is obviously a right solution, you may see people reconsider their opinions. Timeouts wont go away or be deprecated but they could throw unsupported io exceptions for the life of the inputstream returned by getChannel for obvious reasons. Let people try it and give feedback. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Thu May 21 01:19:05 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 21 May 2009 10:19:05 +0300 Subject: [Rxtx] InputStream timeouts Message-ID: <5D23E5B41156B646B2E1A7C2BBA916F317119151B4@SRVFIHKIEXB01.pmgroup.local> Hi Gili, please don't start patronizing. I've been around OO and Design by Contract from around 1986 starting by implementing our own Smalltalk environment. By then I had been writing software for ten years. It is not that I don't understand what you are saying. It is just that I'm not (any more ?!) an OO or DbC zealot. In real world most concepts seem to break down when applied over too wide field. Newtons laws are fine until you get to quantum level. OO is great, but at least so far, it seems that making everything (think integers) objects was a mistake in Smalltalk. You maybe right on the theoretical level, but who cares? Who are you to impose *your* standards on the rest of us? *Every good desing is a compromize.* In this instance I'm 100% sure that the designers of javacomm were well aware of the issues you are complaining about and considered these and many other issues. And their compromise is what we have today.It would belittling them to think otherwise. And to me, even if I think I see where you are coming from, the compromise seem almost perfect for the given problem. To me it is very natural and works almost perfectly despite (or because ?) of the little bending of the rules. Like Steffen(?) wrote here earlier : that (compromise to make it work) is Java all over. And I firmly believe that that is what made Java a success, just like C. Not the prettiest girls in town but very popular... cheers Kusti ________________________________________ From: cowwoc [cowwoc at bbs.darktech.org] Sent: Wednesday, May 20, 2009 9:42 PM To: Kustaa Nyholm Subject: Re: [Rxtx] InputStream timeouts Do me a favor and let me know once you read about Design by Contract. Only then will you be able to understand why RXTX cannot redefine how InputStream works. If subclasses are allowed to modify the contract in an arbitrary manner it defeats the entire concept of Class Inheritance and formal Interfaces. Gili Kustaa Nyholm wrote: > Gili wrote: > >> You have a choice to either break compatibility with old versions of >> RXTX or break compatibility with all other libraries in existence. Both >> options suck, but the latter involves breaking even more code. > > Or, the third option, leave it well alone! Keep it compatible existing code > that is actually using rxtx instead of just worrying about it being correct > to a T. Use it as the creators meant it to be used. Stop worrying about > this. > > >> Right now you cannot safely pass RXTX's InputStream into any other >> library in existence. > > Now that is blatantly untrue. If timeouts are not enable you can pass > it safely to any library. When timeouts are enabled *some* libraries will > not work, some will. If you worry or encounter such a situation you > can then do some wrapper magic. But for pete's sake, let us not disturb > the happy life of rxtx users with well intentioned but misguided zealozy. > > I wonder too how often SerialPort input stream is passed to *any* library? > > I certainly haven't done that ever. > > The way I vision people are using serial port is to talk directly to it > doing most if not all of the protocol handling with custom code, > not with a library. If pass it (the input stream) to a library that chokes on > read returning 0 it is rather your fault for not reading what > the javadoc for SerialPort.getInputStream says! > > cheers Kusti > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Kustaa.Nyholm at planmeca.com Thu May 21 01:20:42 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 21 May 2009 10:20:42 +0300 Subject: [Rxtx] InputStream timeouts Message-ID: <5D23E5B41156B646B2E1A7C2BBA916F317119151B5@SRVFIHKIEXB01.pmgroup.local> Gili wrote: >You have a choice to either break compatibility with old versions of >RXTX or break compatibility with all other libraries in existence. Both >options suck, but the latter involves breaking even more code. Or, the third option, leave it well alone! Keep it compatible existing code that is actually using rxtx instead of just worrying about it being correct to a T. Use it as the creators meant it to be used. Stop worrying about this. > Right now you cannot safely pass RXTX's InputStream into any other >library in existence. Now that is blatantly untrue. If timeouts are not enable you can pass it safely to any library. When timeouts are enabled *some* libraries will not work, some will. If you worry or encounter such a situation you can then do some wrapper magic. But for pete's sake, let us not disturb the happy life of rxtx users with well intentioned but misguided zealozy. I wonder too how often SerialPort input stream is passed to *any* library? I certainly haven't done that ever. The way I vision people are using serial port is to talk directly to it doing most if not all of the protocol handling with custom code, not with a library. If pass it (the input stream) to a library that chokes on read returning 0 it is rather your fault for not reading what the javadoc for SerialPort.getInputStream says! cheers Kusti From Kustaa.Nyholm at planmeca.com Thu May 21 01:49:36 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 21 May 2009 10:49:36 +0300 Subject: [Rxtx] InputStream timeouts - opinions on breaking compatibility? Message-ID: <5D23E5B41156B646B2E1A7C2BBA916F317119151B6@SRVFIHKIEXB01.pmgroup.local> Hi, changed the subject line a bit because I suspect most people have tuned out of this discussion and yet I feel that it is the very people who's input is needed. A month or so ago a lot of people chimed in by telling *what* they do with rxtx, now I would really be interesting to know *how* people are using rxtx? More specifically and relevant to this discussion: 1) are timeouts used? 2) how are they handled? 3) are SerialPort InputStreams passed to library functions? 4) have there been problems (in 3 above)? 5) how would you feel if you would need to rework your code to work with the 'improved' API? The proposal we have (by Gili) is: > 1) add "CommPortChannel getChannel()" This I do not mind so much as I do not need to touch my code. > 2) deprecate getInputStream() and enableReceiveTimeout() in favor of > getChannel() This I object to very much. One of my coding 'rules' say do-not-use-deprecated methods. An other rule says that my compiles-should-be-clean, so this would need me to change my code. Also, this is imposing and force feeding things to people who can't appreciate the beauty of the 'improvements' and are against them. > 3) getChannel() will return a class that implements the same interfaces as > SocketChannel. It will allow both blocking and non-blocking I/O operations. As I will not be using that (getChannel()) I don't care so much, but I bet this will be a new can worms having just the same sort of issues and compromises as we have been discussing here. But it would really be educational and fun to see proposers eat their own dog meat, so yes, let's do this! > 4) In RXTX 3.0 getInputStream() will return an InputStream that always blocks > on reads and the method will be undeprecated. > Just great, this is the top, I'm totally against this. Not only did (2) above require me to rework my code but now in phase two I would need to rework my code again to comply with yet another API change. There has to be better things in life and coding than tracking ever changing APIs! I'm involved in several projects ranging from a few thousand lines to several thousand hand written classes. Javacomm and rxtx play a small but crucial part in these. I would very much like to spend time on improving the applications instead of tracking changes in different APIs (not limited to rxtx). Especially changes that IMO only bring internal beauty . Our current code works and has been debugged to with the current API design, no compelling reason has been put forward to change the API and throw away the (albeit not so big) investment in learning to use the current API and making our code to work with it. All I care is that I have a cross platform serial port API that is stable and works as advertised, and which I do not have to implement and test on all the platforms. So far rxtx has been just wonderful, let's keep it that way. my 2 snt worth, cheers Kusti From michaeltandy at googlemail.com Thu May 21 05:48:44 2009 From: michaeltandy at googlemail.com (Michael Tandy) Date: Thu, 21 May 2009 12:48:44 +0100 Subject: [Rxtx] Buffer overflow caused by fhs_lock error message Message-ID: <302aa0340905210448v46b7ee61j58787b10500411b@mail.gmail.com> When, on Linux, one attempts to open a device such as /dev/ttyUSB71 and the device is locked, Java crashes with this error message: *** buffer overflow detected ***: java terminated ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7ead6d8] /lib/tls/i686/cmov/libc.so.6[0xb7eab800] /lib/tls/i686/cmov/libc.so.6[0xb7eaaef8] /lib/tls/i686/cmov/libc.so.6(_IO_default_xsputn+0xc8)[0xb7e20a78] /lib/tls/i686/cmov/libc.so.6(_IO_vfprintf+0x6f3)[0xb7df30b3] /lib/tls/i686/cmov/libc.so.6(__vsprintf_chk+0xa4)[0xb7eaafa4] /lib/tls/i686/cmov/libc.so.6(__sprintf_chk+0x2d)[0xb7eaaeed] /home/michael/Documents/asdf/lib/librxtxSerial.so(fhs_lock+0x1c2)[0xb4b82cf2] /home/michael/Documents/asdf/lib/librxtxSerial.so(Java_gnu_io_RXTXCommDriver_testRead+0x80)[0xb4b838a0] This is caused because trying to sprintf the error message, the device name, the error description, the newline and then null terminate the string overflows the 80 characters allocated. The problem code seems to be: char message[80]; sprintf( message,"RXTX fhs_lock() Error: creating lock file: %s: %s\n", file, strerror(errno) ); A switch to the buffer-overflow-proof snprintf function fixes the problem by truncating the error message if it exceeds 79 characters: char message[80]; snprintf( message, 80, "RXTX fhs_lock() Error: creating lock file: %s: %s\n", file, strerror(errno) ); A patch is attached to apply this fix - although there might be other bugs of this class in rxtx; it might be worth applying this fix anywhere sprintf is currently used. Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: overflowpatch.diff Type: application/octet-stream Size: 1133 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090521/3a487d21/attachment-0003.obj From rxtx at qbang.org Thu May 21 09:48:47 2009 From: rxtx at qbang.org (VIAGRA ® Official Site) Date: Thu, 21 May 2009 09:48:47 -0600 Subject: [Rxtx] Dear rxtx@qbang.org SALE 77% 0FF on Pfizer ! Message-ID: <200905211548.n4LFmltZ029873@rxtx.qbang.org> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090521/c9af7fb9/attachment-0002.html From Klaus.Kierer at Tiscover.com Thu May 21 10:02:52 2009 From: Klaus.Kierer at Tiscover.com (Kierer, Klaus) Date: Thu, 21 May 2009 18:02:52 +0200 Subject: [Rxtx] Abwesenheitsnotiz: URL Filtering: Re: Dear rxtx@qbang.org SALE 77% 0FF on Pfizer ! Message-ID: <65FE44E2CAED5742B96A161F3703A5390861B0F5@ibk-tis-mx-01.tiscover.corp> Vielen Dank f?r Ihre Nachricht. Ich bin leider bis Montag, 25 Mai au?er Haus und werde mich erst anschlie?end um Ihr Anliegen k?mmern k?nnen. In dringenden F?llen senden Sie daher bitte ein Email an alexander.sommer at tiscover.com. Danke. Mit freundlichen Gr??en Klaus Kierer www.tiscover.com Thank you for your message. I am currently not contactable until Monday, 25th of May and thus cannot respond to your message until then. If your enquiry is urgent, please contact alexander.sommer at tiscover.com. Thank you. Kind Regards Klaus Kierer www.tiscover.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090521/0d4f9c57/attachment-0002.html From pixue_breaker at hotmail.com Fri May 22 02:35:41 2009 From: pixue_breaker at hotmail.com (=?iso-8859-1?Q?Samuel_Ovia=F1o_Su=E1rez?=) Date: Fri, 22 May 2009 08:35:41 +0000 Subject: [Rxtx] porting rxtx to avr32-linux Message-ID: Hi! I'm trying to port rxtx to avr32-linux. My objetive is executing a serial comm app with jamvm running on avr32-linux platform so i need the suitable librxtxSerial.so for this. I have started to work in that following the next steps: 1. input : ./autogen.sh --host=avr32-linux --target=avr32-linux output : You should update your `aclocal.m4' by running aclocal acinclude.m4:6193: the serial number must appear before any macro definition 2. I updated aclocal comment out line 6193 of acinlcude.m4 and then i typed 'aclocal' 3. input: ./configure --host=avr32-linux --target=avr32-linux output: the makefile with avr32-linux settings After, i tried to 'make install' but compilation process stopped with this error: /home/samuel/Escritorio/rxtx-2.1-7r2/./src/SerialImp.h:441: error: expected declaration specifiers or '...' before 'wchar_t' avr32-linux-gcc -I/home/samuel/Escritorio/rxtx-2.1-7r2 -Iavr32-unknown-linux-gnu -I. -I/usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/include -I/usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/include/./ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c /home/samuel/Escritorio/rxtx-2.1-7r2/./src/fuserImp.c -fPIC -DPIC -o /home/samuel/Escritorio/rxtx-2.1-7r2/avr32-unknown-linux-gnu/.libs/fuserImp.o libtool: link: `/home/samuel/Escritorio/rxtx-2.1-7r2/avr32-unknown-linux-gnu/SerialImp.lo' is not a valid libtool object make: *** [avr32-unknown-linux-gnu/librxtxSerial.la] Error 1 What's wrong? Thanks in advance, Pixueto _________________________________________________________________ ?Qu?tate unos clics! Ahora, Internet Explorer 8 tiene todo lo que te gusta de Windows Live ?Cons?guelo gratis! http://ie8.msn.com/microsoft/internet-explorer-8/es-es/ie8.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090522/87e7bc4d/attachment-0002.html From tjarvi at qbang.org Fri May 22 09:05:44 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 May 2009 09:05:44 -0600 (MDT) Subject: [Rxtx] porting rxtx to avr32-linux In-Reply-To: References: Message-ID: On Fri, 22 May 2009, Samuel Ovia?o Su?rez wrote: > Hi! > > I'm trying to port rxtx to avr32-linux. My objetive is executing a serial comm app with jamvm running on avr32-linux platform so i need the suitable > librxtxSerial.so for this. I have started to work in that following the next steps: > > 1. input : ./autogen.sh --host=avr32-linux --target=avr32-linux > ??? output : You should update your `aclocal.m4' by running aclocal > ?????????????????? acinclude.m4:6193: the serial number must appear before any macro definition > > 2. I updated aclocal comment out line 6193 of acinlcude.m4 and then i typed 'aclocal' > > 3. input: ./configure --host=avr32-linux --target=avr32-linux > ??? output: the makefile with avr32-linux settings > > After, i tried to 'make install' but compilation process stopped with this error: > > /home/samuel/Escritorio/rxtx-2.1-7r2/./src/SerialImp.h:441: error: expected declaration specifiers or '...' before 'wchar_t' > ?avr32-linux-gcc -I/home/samuel/Escritorio/rxtx-2.1-7r2 -Iavr32-unknown-linux-gnu -I. -I/usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/include > -I/usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/include/./ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c > /home/samuel/Escritorio/rxtx-2.1-7r2/./src/fuserImp.c? -fPIC -DPIC -o /home/samuel/Escritorio/rxtx-2.1-7r2/avr32-unknown-linux-gnu/.libs/fuserImp.o > libtool: link: `/home/samuel/Escritorio/rxtx-2.1-7r2/avr32-unknown-linux-gnu/SerialImp.lo' is not a valid libtool object > make: *** [avr32-unknown-linux-gnu/librxtxSerial.la] Error 1 > > What's wrong? > > Thanks in advance, Hi Pixueto I don't think autogen.sh takes arguments. Perhaps you are used to a newer version of the same script. The arguments should be ignored. .m4 files are beyond me. Your hack is typical of what I do but I've not made rules before. Is line 441 in SerialImp.h 'extern int mexPrintf( const char *, ... );" ? If so, you do not want to turn on DEBUG_MW. Those functions are an older way of printing debug information in MATLAB. -- Trent Jarvi tjarvi at mathworks.com From Bob_Jacobsen at lbl.gov Fri May 22 10:05:12 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Fri, 22 May 2009 09:05:12 -0700 Subject: [Rxtx] InputStream timeouts - opinions on breaking compatibility? In-Reply-To: <5D23E5B41156B646B2E1A7C2BBA916F317119151B6@SRVFIHKIEXB01.pmgroup.local> References: <5D23E5B41156B646B2E1A7C2BBA916F317119151B6@SRVFIHKIEXB01.pmgroup.local> Message-ID: At 10:49 AM +0300 5/21/09, Kustaa Nyholm wrote: >A month or so ago a lot of people chimed in by telling *what* they >do with rxtx, >now I would really be interesting to know *how* people are using rxtx? > >More specifically and relevant to this discussion: > >1) are timeouts used? Yes, because on some platforms/protocols it's the only known way to get the last read character. >2) how are they handled? Just repeat the read >3) are SerialPort InputStreams passed to library functions? Yes. >4) have there been problems (in 3 above)? No. >5) how would you feel if you would need to rework your code to work >with the 'improved' API? If you changed the API? Very, very unhappy. >The proposal we have (by Gili) is: > > > 1) add "CommPortChannel getChannel()" > No objection, but no plans to use on any reasonable timescale. > > 2) deprecate getInputStream() and enableReceiveTimeout() in favor of > > getChannel() > You should only deprecate something you intend to eventually remove. What's the reason to _remove_ these? They do what they do. > > 3) getChannel() will return a class that implements the same interfaces as > > SocketChannel. It will allow both blocking and non-blocking I/O operations. > If this is going to be done, somebody should _first_ write a very detailed API of what the SocketChannel interface "means" for serial communications (which isn't just bytes and EOF). > > 4) In RXTX 3.0 getInputStream() will return an InputStream that >always blocks >> on reads and the method will be undeprecated. >> Very, very opposed to this. If you want to provide another interface, fine, but don't hijack an existing one. This will result in significant maintenance problems as people have to mix and match various versions of RXTX for concurrent use. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From cowwoc at bbs.darktech.org Fri May 22 10:29:39 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 22 May 2009 12:29:39 -0400 Subject: [Rxtx] InputStream timeouts - opinions on breaking compatibility? In-Reply-To: References: <5D23E5B41156B646B2E1A7C2BBA916F317119151B6@SRVFIHKIEXB01.pmgroup.local> Message-ID: <4A16D2F3.2000607@bbs.darktech.org> Bob Jacobsen wrote: >> 3) are SerialPort InputStreams passed to library functions? > > Yes. Related question: which classes do you pass RXTX's InputStream to? Gili From luis.moreira at ntlworld.com Sat May 2 00:39:04 2009 From: luis.moreira at ntlworld.com (luis.moreira at ntlworld.com) Date: Sat, 2 May 2009 7:39:04 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Hi Travis, The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. The issues I still have is the errors after that. Do you have any idea what can be causing this errors? _______________________________________________________________________________ conftest.c: In function 'main': conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) conftest.c:8: error: (Each undeclared identifier is reported only once conftest.c:8: error: for each function it appears in.) conftest.c:8: error: expected ')' before string constant conftest.c:8: warning: format not a string literal and no format arguments ./configure: line 21462: ./conftest: No such file or directory ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands ------------------------------------------------------------------------------- I don't know what happened to my previous post, it as not showed up in the list. Best Regards Luis From tjarvi at qbang.org Sat May 2 07:30:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 07:30:04 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> References: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Message-ID: On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > Hi Travis, > The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. > The issues I still have is the errors after that. Do you have any idea what can be causing this errors? > > _______________________________________________________________________________ > conftest.c: In function 'main': > conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) > conftest.c:8: error: (Each undeclared identifier is reported only once > conftest.c:8: error: for each function it appears in.) > conftest.c:8: error: expected ')' before string constant > conftest.c:8: warning: format not a string literal and no format arguments > ./configure: line 21462: ./conftest: No such file or directory > ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: config.h is unchanged > config.status: executing depfiles commands > ------------------------------------------------------------------------------- > > This was corrected in CVS. I think you can just do the following in the top directory: cvs login: (pw is mousy) cvs update That will get the current fixes. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sat May 2 16:14:50 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sat, 02 May 2009 23:14:50 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FCC5DA.6000700@ntlworld.com> Trent Jarvi wrote: > > > On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > >> Hi Travis, >> The problem with the Makefile is not a problem,When I run ./configure >> I make a new Makefile with the same data in it, hence what I just >> modified is removed. >> The issues I still have is the errors after that. Do you have any >> idea what can be causing this errors? >> >> _______________________________________________________________________________ >> >> conftest.c: In function 'main': >> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >> function) >> conftest.c:8: error: (Each undeclared identifier is reported only once >> conftest.c:8: error: for each function it appears in.) >> conftest.c:8: error: expected ')' before string constant >> conftest.c:8: warning: format not a string literal and no format >> arguments >> ./configure: line 21462: ./conftest: No such file or directory >> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >> expected >> configure: creating ./config.status >> config.status: creating Makefile >> config.status: creating config.h >> config.status: config.h is unchanged >> config.status: executing depfiles commands >> ------------------------------------------------------------------------------- >> >> >> > > This was corrected in CVS. I think you can just do the following in > the top directory: > > cvs login: (pw is mousy) > cvs update > > That will get the current fixes. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, apologies for the mix-up of your name. I managed to get further on by updating CVS, the configure command gets to the end without any errors, it still warns me that it is confused about where to find the jni_md.h but I just edited the Makefile and sorted that out. I then run make, with no parameters following the instructions on the Wiki, but that generated a few more errors: ----------------------------------------------------------------------------------------------------------------------- gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. -I/usr/lib/jvm/java-6-openjdk/include /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' undeclared (first use in this function) /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared identifier is reported only once /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each function it appears in.) libtool: link: `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 ----------------------------------------------------------------------------------------------------------------------- Another question I have is, in which folder will the .so files be placed after make finishes? thank you very much for your help. Best Regards Luis From tjarvi at qbang.org Sat May 2 19:27:08 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 19:27:08 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FCC5DA.6000700@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> Message-ID: On Sat, 2 May 2009, Luis Moreira wrote: > Trent Jarvi wrote: >> >> >> On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: >> >>> Hi Travis, >>> The problem with the Makefile is not a problem,When I run ./configure >>> I make a new Makefile with the same data in it, hence what I just >>> modified is removed. >>> The issues I still have is the errors after that. Do you have any >>> idea what can be causing this errors? >>> >>> _______________________________________________________________________________ >>> >>> conftest.c: In function 'main': >>> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >>> function) >>> conftest.c:8: error: (Each undeclared identifier is reported only once >>> conftest.c:8: error: for each function it appears in.) >>> conftest.c:8: error: expected ')' before string constant >>> conftest.c:8: warning: format not a string literal and no format >>> arguments >>> ./configure: line 21462: ./conftest: No such file or directory >>> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >>> expected >>> configure: creating ./config.status >>> config.status: creating Makefile >>> config.status: creating config.h >>> config.status: config.h is unchanged >>> config.status: executing depfiles commands >>> ------------------------------------------------------------------------------- >>> >>> >>> >> >> This was corrected in CVS. I think you can just do the following in >> the top directory: >> >> cvs login: (pw is mousy) >> cvs update >> >> That will get the current fixes. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > apologies for the mix-up of your name. > I managed to get further on by updating CVS, the configure command gets > to the end without any errors, it still warns me that it is confused > about where to find the jni_md.h but I just edited the Makefile and > sorted that out. > I then run make, with no parameters following the instructions on the > Wiki, but that generated a few more errors: > ----------------------------------------------------------------------------------------------------------------------- > > gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. > -I/usr/lib/jvm/java-6-openjdk/include > /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE > -D_BSD_SOURCE -D__need_timespec -c > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o > /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' > undeclared (first use in this function) > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared > identifier is reported only once > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each > function it appears in.) > libtool: link: > `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a > valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 > ----------------------------------------------------------------------------------------------------------------------- > > Another question I have is, in which folder will the .so files be placed > after make finishes? > > thank you very much for your help. > Ah when you do cvs update pass the -Pd option cvs update -Pd Also, when you run configure, use --disable-PRINTER to only build the serial support. It will make things easier. --disable-LOCKFILES will also be easier to get going until you want to learn about how to prevent multiple applications from reading the same serial port. The link for debugging will describe where the files go. By default, it will install in the JRE/JDK under jre/lib/ext (the jar file) jre/lib/i386 (the .so file) Those are on the proper paths when you use the sun or ibm jdk. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sun May 3 01:30:43 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sun, 03 May 2009 08:30:43 +0100 Subject: [Rxtx] First use of RXTX package In-Reply-To: References: <49FCC5DA.6000700@ntlworld.com> Message-ID: <49FD4823.5080204@ntlworld.com> Ah > > when you do cvs update pass the -Pd option > > cvs update -Pd > > Also, when you run configure, use --disable-PRINTER to only build the > serial support. It will make things easier. --disable-LOCKFILES will > also be easier to get going until you want to learn about how to > prevent multiple applications from reading the same serial port. > > The link for debugging will describe where the files go. By default, > it will install in the JRE/JDK under > > jre/lib/ext (the jar file) > jre/lib/i386 (the .so file) > > Those are on the proper paths when you use the sun or ibm jdk. > > http://rxtx.qbang.org/wiki/index.php/Trouble_shooting > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, It as done it! I think this instructions you gave me should be on the Wiki, I can write them for you if you like. Also on the Wiki when you describe the three methods of installing the RxTx package it is confusing because as far as I can see, you always have to do method 1 or the .so files will not be generated(is this correct?). Then you can if you like change the location with method 1 & 2. Is it possible to modify the .la file to point to different directories for installation and then you can decide where to place the files? In a way I have learned quite a lot about Linux by having to struggle, with your help, to find solutions to the problems I encountered (I am still very new to Linux), but maybe we need to log these problems somewhere to make it less of a struggle for others like me. I have used the PortLister example to test it and it came up with my USB to dual Serial adaptor Ports. I will now explore the RxTx package, before I tackle the windows installation, I will let you know of my experience. Thank you for all your Help. Best Regards Luis From tjarvi at qbang.org Sun May 3 10:37:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 3 May 2009 10:37:50 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FD4823.5080204@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> <49FD4823.5080204@ntlworld.com> Message-ID: On Sun, 3 May 2009, Luis Moreira wrote: > Ah >> >> when you do cvs update pass the -Pd option >> >> cvs update -Pd >> >> Also, when you run configure, use --disable-PRINTER to only build the >> serial support. It will make things easier. --disable-LOCKFILES will >> also be easier to get going until you want to learn about how to >> prevent multiple applications from reading the same serial port. >> >> The link for debugging will describe where the files go. By default, >> it will install in the JRE/JDK under >> >> jre/lib/ext (the jar file) >> jre/lib/i386 (the .so file) >> >> Those are on the proper paths when you use the sun or ibm jdk. >> >> http://rxtx.qbang.org/wiki/index.php/Trouble_shooting >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > It as done it! > I think this instructions you gave me should be on the Wiki, I can write > them for you if you like. Also on the Wiki when you describe the three > methods of installing the RxTx package it is confusing because as far > as I can see, you always have to do method 1 or the .so files will not > be generated(is this correct?). Then you can if you like change the > location with method 1 & 2. Is it possible to modify the .la file to > point to different directories for installation and then you can decide > where to place the files? > In a way I have learned quite a lot about Linux by having to struggle, > with your help, to find solutions to the problems I encountered (I am > still very new to Linux), but maybe we need to log these problems > somewhere to make it less of a struggle for others like me. > > I have used the PortLister example to test it and it came up with my USB > to dual Serial adaptor Ports. > > I will now explore the RxTx package, before I tackle the windows > installation, I will let you know of my experience. > > Thank you for all your Help. > Hi Luis, The locations suggested for first time configuration could be documented in a new wiki page explaining that this is not the recommended general workflow but does help new users that are not worried about having rxtx installed into the JRE. For a professional environment, the user would want to follow the workflow currently on the wiki and keep their JRE clean. Often the user will not be able to add libraries to the JRE and will need to use their home directory or a sandbox. Feel free to add information to the wiki. I'd suggest creating comment in the current page and have the comment link to what worked for you as a first time user new to Linux. You can create a new page with your comments. In the long term, we will be working on an autoinstaller that works over the web. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Mon May 4 09:15:40 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Mon, 04 May 2009 16:15:40 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FF069C.8040406@ntlworld.com> Hi Trent, I have now installed the package on my 64 bit machine and when I run my program I get errors on the attachment. I know it as something to do with the architecture of my system but I can no figure out how to fix it. I have built it from source again, I did not transfer the files from machine to machine. can you please put me in the right direction. Thank you very much for your help. Best Regards Luis -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshoot.png Type: image/png Size: 25753 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090504/141ab5dc/attachment-0020.png From johnny.luong at trustcommerce.com Mon May 4 11:57:08 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 04 May 2009 10:57:08 -0700 Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FF069C.8040406@ntlworld.com> References: <49FF069C.8040406@ntlworld.com> Message-ID: <49FF2C74.90805@trustcommerce.com> Luis Moreira wrote: > Hi Trent, > I have now installed the package on my 64 bit machine and when I run my > program I get errors on the attachment. I know it as something to do > with the architecture of my system but I can no figure out how to fix > it. I have built it from source again, I did not transfer the files from > machine to machine. > can you please put me in the right direction. > Thank you very much for your help. > Best Regards > Luis > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Hi, Does running it on a 64-bit JVM help? Your host environment might be building objects for a 64-bit environment unless you did a cross-compile... -- you can find out by doing something like the following: johnny at spike:~$ java -version java version "1.6.0_0" OpenJDK Runtime Environment (build 1.6.0_0-b11) OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode) johnny at spike:~$ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) -Johnny From huangdongkai at gmail.com Wed May 6 11:06:06 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 01:06:06 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. Message-ID: Dear all, I recompile the rxtxSerial source code by MinGW32 and compile success. But when I run my Application which use rxtxSerial.dll to communicate with serial port, a runtime exception happened and application crash. I have no idea why it can not work, beacuse i have not change any source code of rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I have missed when compile the source code on Window NT? Here below is the output error massage. # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, tid=1360 # # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing windows-x86) # Problematic frame: # V [jvm.dll+0x1b6824] # # An error report file with more information is saved as: # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/32c1e699/attachment-0018.html From tjarvi at qbang.org Wed May 6 20:04:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 May 2009 20:04:10 -0600 (MDT) Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: On Thu, 7 May 2009, dongkai huang wrote: > Dear all, > ????? I recompile the rxtxSerial source code by MinGW32 and compile success. > But when I run my Application which use rxtxSerial.dll to communicate with > serial port, a runtime exception happened and application crash.? I have no > idea why it can not work, beacuse i have not change any source code of > rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I > have missed when compile the source code on Window NT? Here below is the > output error massage. > # > # An unexpected error has been detected by Java Runtime Environment: > # > #? EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, > tid=1360 > # > # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing > windows-x86) > > # Problematic frame: > # V? [jvm.dll+0x1b6824] > # > # An error report file with more information is saved as: > # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log > # > # If you would like to submit a bug report, please visit: > #?? http://java.sun.com/webapps/bugreport/crash.jsp > # > > > Hi Dongkai Could you explain how you compiled rxtx with mingw? Did you run configure? Was the compiler native or a cross compiler (like compiling on Linux for Windows)? Is the crash happening when you first open the port or is it happening randomly later on? -- Trent Jarvi tjarvi at qbang.org From huangdongkai at gmail.com Wed May 6 20:48:56 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 10:48:56 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Hi Trent, I was followed the step on INSTALL file, did not run the configure, I used the Makefile.mingw32 which include on the source code package, and only change some path( jdk home path etc.). And I use the native compiler on Windows. The crash happened on I call the getPortIdentifiers() every time. On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Dear all, >> I recompile the rxtxSerial source code by MinGW32 and compile >> success. >> But when I run my Application which use rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and application crash. I have >> no >> idea why it can not work, beacuse i have not change any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing >> I >> have missed when compile the source code on Window NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is saved as: >> # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> > Hi Dongkai > > Could you explain how you compiled rxtx with mingw? Did you run configure? > Was the compiler native or a cross compiler (like compiling on Linux for > Windows)? > > Is the crash happening when you first open the port or is it happening > randomly later on? > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/733eded5/attachment-0018.html From m.j.tandy at warwick.ac.uk Thu May 7 10:39:12 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 7 May 2009 17:39:12 +0100 Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. Message-ID: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> I've encountered a bug in how XON/XOFF are handled on Windows. The symptoms were: 1. XON/XOFF from device to PC did not stop transmission. 2. XON/XOFF characters were present in data read from serial port input stream, when it was expected that they would be stripped out. 3. Investigation with SysInternals PortMon revealed the following configuration when using rxtx: 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 while HyperTerminal, which did not have the same problems as me, produced the following: 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 In other words, the problem is that, in addition to being told to use XON/XOFF flow control, the computer has to explicitly be told which characters to use for 'XON' and 'XOFF'. This part of the configuration was being missed out. I got the latest rxtx source from CVS, and identified the problem as an omission in the 'init_termios' function of 'termios.c', which configures the unix/termios 'c_cc' (control characters) data structure - but omits to configure the VSTART and VSTOP control characters. Later, the termios c_cc data structure is translated (by termios_to_DCB) into a data structure named 'DCB', which is passed to the windows serial port configuration interface. By adding two lines defining the standard XON/XOFF characters to the function init_termios, the bug is fixed. A patch doing this is attached. Thanks, Michael Tandy -------------- next part -------------- A non-text attachment was scrubbed... Name: xon-xoff.diff Type: application/octet-stream Size: 667 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/159c0dcc/attachment-0017.obj From tjarvi at qbang.org Thu May 7 17:57:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 May 2009 17:57:28 -0600 (MDT) Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. In-Reply-To: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> References: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> Message-ID: On Thu, 7 May 2009, Michael Tandy wrote: > I've encountered a bug in how XON/XOFF are handled on Windows. > > The symptoms were: > 1. XON/XOFF from device to PC did not stop transmission. > 2. XON/XOFF characters were present in data read from serial port > input stream, when it was expected that they would be stripped out. > 3. Investigation with SysInternals PortMon revealed the following > configuration when using rxtx: > > 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 > BRK:0 EVT:a XON:0 XOFF:0 > > while HyperTerminal, which did not have the same problems as me, > produced the following: > > 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 > > In other words, the problem is that, in addition to being told to use > XON/XOFF flow control, the computer has to explicitly be told which > characters to use for 'XON' and 'XOFF'. This part of the configuration > was being missed out. > > I got the latest rxtx source from CVS, and identified the problem as > an omission in the 'init_termios' function of 'termios.c', which > configures the unix/termios 'c_cc' (control characters) data structure > - but omits to configure the VSTART and VSTOP control characters. > Later, the termios c_cc data structure is translated (by > termios_to_DCB) into a data structure named 'DCB', which is passed to > the windows serial port configuration interface. > > By adding two lines defining the standard XON/XOFF characters to the > function init_termios, the bug is fixed. A patch doing this is > attached. > Thanks Michael, Good timing. I plan on releasing rxtx-2.2 this coming Sunday. -- Trent Jarvi tjarvi at qbang.org From wjr at weru.ksu.edu Fri May 8 11:38:29 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Fri, 08 May 2009 12:38:29 -0500 Subject: [Rxtx] swing jfilechooser lockup Message-ID: <4A046E15.6010907@weru.ksu.edu> Hi, I wrote a small swing app to download images from an industrial camera. I used the two way serial sample code as a starting point. The app works fine EXCEPT for a call to jfilechooser. After I open the comm port and then try to change the output directory or log file, the jfilechooser winds up trying to unpark (note, parking is not something I'm really familiar with) and doesn't. If I try to change the file or directory before I start the comm port, it works. If I click on menu items that don't call jfilechooser, everything is OK. If I try closing the comm port and then try to create a jfilechooser, it locks up. There is obviously some sort of deadlock here because the awt thread starts waiting on something but it's not clear what. I haven't gone thru the rxtx code yet because it's not in the file structure that netbeans wants for debugging purposes. However, debugging code that I don't have a clear idea of what it is supposed to do is not my idea of a good time. Does anyone have any ideas on what is going on here? Thanks, wjr From Bob_Jacobsen at lbl.gov Fri May 8 14:48:25 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Fri, 8 May 2009 13:48:25 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A046E15.6010907@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> Message-ID: At 12:38 PM -0500 5/8/09, Bill Rust wrote: >Hi, > >I wrote a small swing app to download images from an industrial camera. >I used the two way serial sample code as a starting point. The app works >fine EXCEPT for a call to jfilechooser. After I open the comm port and >then try to change the output directory or log file, the jfilechooser >winds up trying to unpark (note, parking is not something I'm really >familiar with) and doesn't. If I try to change the file or directory >before I start the comm port, it works. If I click on menu items that >don't call jfilechooser, everything is OK. If I try closing the comm >port and then try to create a jfilechooser, it locks up. There is >obviously some sort of deadlock here because the awt thread starts >waiting on something but it's not clear what. I haven't gone thru the >rxtx code yet because it's not in the file structure that netbeans wants >for debugging purposes. However, debugging code that I don't have a >clear idea of what it is supposed to do is not my idea of a good time. What is the threading structure of your code? The various high-function Swing components, such as JFileChooser, are notorious for doing Really Bad Stuff when invoked from off the Swing thread. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From bschlining at gmail.com Fri May 8 15:08:50 2009 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 8 May 2009 14:08:50 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: Bob's probably right...take look at javax.swing.SwingUtilites for the workaround to get your swing stuff invoked on the EventDispatchThread (EDT). Some swing-methods do work when called outside of the EDT, but just to be safe, do your creation and swing calls on the EDT. It's really simple, here's an example of a synchronous call. // Here's how to run stuff on the EDT from a different thread SwingUtilities.invokeAndWait(new Runnable() { public void run() { JFileChooser fc; // create, setup, show your filechooser // Get the result from the filechooser } }); To do a asynchronous call use SwingUtilities.invokeLater > >I wrote a small swing app to download images from an industrial camera. > >I used the two way serial sample code as a starting point. The app works > >fine EXCEPT for a call to jfilechooser. After I open the comm port and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090508/c21c2127/attachment-0016.html From tod at todbot.com Fri May 8 16:27:12 2009 From: tod at todbot.com (Tod E. Kurt) Date: Fri, 8 May 2009 15:27:12 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> This is the exact technique I use to let the user choose which serial port to use on startup. Here's a method I've got in many of my sketches: void choosePort() { String portlist[] = Serial.list(); String port = null; javax.swing.SwingUtilities.invokeLater(new Runnable() { public void run() { try { String port = (String) javax.swing.JOptionPane.showInputDialog( null, "Select Serial Port", "MySuperSketch", javax.swing.JOptionPane.QUESTION_MESSAGE, null, portlist, null); if( port == null ) { javax.swing.JOptionPane.showMessageDialog(null, "No port chosen, goodbye"); System.exit(1); } serialPort = port; } catch (Exception e) { e.printStackTrace(); } } } ); } On May 8, 2009, at 2:08 p, Brian Schlining wrote: > Bob's probably right...take look at javax.swing.SwingUtilites for > the workaround to get your swing stuff invoked on the > EventDispatchThread (EDT). Some swing-methods do work when called > outside of the EDT, but just to be safe, do your creation and swing > calls on the EDT. It's really simple, here's an example of a > synchronous call. > > // Here's how to run stuff on the EDT from a different thread > SwingUtilities.invokeAndWait(new Runnable() { > public void run() { > JFileChooser fc; // create, setup, show your filechooser > // Get the result from the filechooser > } > }); > > To do a asynchronous call use SwingUtilities.invokeLater > > > >I wrote a small swing app to download images from an industrial > camera. > >I used the two way serial sample code as a starting point. The app > works > >fine EXCEPT for a call to jfilechooser. After I open the comm port > and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From huangdongkai at gmail.com Sat May 9 04:46:22 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Sat, 9 May 2009 18:46:22 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Dear Trent, After I intsall the ming32-cross compile to compile the rxtxSerial.dll and testing, i found the same problem still exist. I am not sure my compiler version is the same as your's. Could you tell me the way you can success compile rxtx-2.1-7r2 release source code? Thanks for you kindly help. On Fri, May 8, 2009 at 8:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Hi Trent, >> The attach is the Make file I use to compile the rxtx. >> >> On Thu, May 7, 2009 at 10:48 AM, dongkai huang >> wrote: >> Hi Trent, >> I was followed the step on INSTALL file, did not run the >> configure, I used the Makefile.mingw32 which include on the >> source code package, and only change some path( jdk home path >> etc.). And I use the native compiler on Windows. >> The crash happened on I call the getPortIdentifiers() >> every time. >> >> On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: >> >> >> On Thu, 7 May 2009, dongkai huang wrote: >> >> Dear all, >> I recompile the rxtxSerial source code by >> MinGW32 and compile success. >> But when I run my Application which use >> rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and >> application crash. I have no >> idea why it can not work, beacuse i have not change >> any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source >> code. Did some thing I >> have missed when compile the source code on Window >> NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java >> Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at >> pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 >> mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is >> saved as: >> # >> D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please >> visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> >> Hi Dongkai >> >> Could you explain how you compiled rxtx with mingw? Did you run >> configure? Was the compiler native or a cross compiler (like >> compiling on Linux for Windows)? >> >> Is the crash happening when you first open the port or is it >> happening randomly later on? >> >> > Thanks Dongkai > > I'll look at your Makefile tomorrow. Which version of mingw was this? > > I suspect there is a problem with that makefile. I usually built that > version of rxtx for windows with a mingw32 cross compiler using the > configure script. > > The configure script may well work for you if you have a cygwin environment > with mingw instead of gcc. I'll take a look at what is different. > > -- > > Trent Jarvi > tjarvi at qbang.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090509/b729c429/attachment-0016.html From wjr at weru.ksu.edu Wed May 13 15:50:30 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Wed, 13 May 2009 16:50:30 -0500 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> Message-ID: <4A0B40A6.5070204@weru.ksu.edu> Tod's solution misses the point. He is picking and opening the serial port. That's the step before where my problem occurs. To recap: 1. I have a simple java swing app. 2. On the menu bar, there is the standard set, file, etc., of jmenu's. Under file, there is a jmenuitem, logfileopen, which pops up a jfilechooser to select a logfile and another jmenuitem, setprefix, which pops up a jdialog to allow the user to type in a file name prefix for downloaded images. 3. There is another jmenuitem that starts the commport running. 4. When logfileopen is pressed before the commport is started, it works. 5. When logfileopen is pressed after the commport is started, it hangs. 6. setprefix works whether or not the commport is started. 7. portIdentifier.open starts a thread that goes into a native method, RXTXPort.eventLoop, and never returns. 8. java.sun bugs has a bug report, 6741890, that is similar but their workaround doesn't. 9. When it locks up, there is a swing-shell thread that appears to be down in some native libraries, winshellfolder2 10. The awt-eventQ thread is unblocked but in code that says its parked. If you have anymore ideas, I'd really appreciate them. wjr Tod E. Kurt wrote: > This is the exact technique I use to let the user choose which serial > port to use on startup. Here's a method I've got in many of my sketches: > > void choosePort() { > String portlist[] = Serial.list(); > String port = null; > javax.swing.SwingUtilities.invokeLater(new Runnable() { > public void run() { > try { > String port = (String) javax.swing.JOptionPane.showInputDialog( > null, > "Select Serial Port", > "MySuperSketch", > javax.swing.JOptionPane.QUESTION_MESSAGE, > null, portlist, null); > if( port == null ) { > javax.swing.JOptionPane.showMessageDialog(null, "No port > chosen, goodbye"); > System.exit(1); > } > serialPort = port; > } > catch (Exception e) { > e.printStackTrace(); > } > } > } ); > } > > > On May 8, 2009, at 2:08 p, Brian Schlining wrote: > >> Bob's probably right...take look at javax.swing.SwingUtilites for the >> workaround to get your swing stuff invoked on the EventDispatchThread >> (EDT). Some swing-methods do work when called outside of the EDT, but >> just to be safe, do your creation and swing calls on the EDT. It's >> really simple, here's an example of a synchronous call. >> >> // Here's how to run stuff on the EDT from a different thread >> SwingUtilities.invokeAndWait(new Runnable() { >> public void run() { >> JFileChooser fc; // create, setup, show your filechooser >> // Get the result from the filechooser >> } >> }); >> >> To do a asynchronous call use SwingUtilities.invokeLater >> >> >> >I wrote a small swing app to download images from an industrial camera. >> >I used the two way serial sample code as a starting point. The app works >> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >> >then try to change the output directory or log file, the jfilechooser >> >winds up trying to unpark (note, parking is not something I'm really >> >familiar with) and doesn't. >> What is the threading structure of your code? >> >> The various high-function Swing components, such as JFileChooser, are >> notorious for doing Really Bad Stuff when invoked from off the Swing >> thread. >> >> Bob >> -- >> Bob Jacobsen, UC Berkeley >> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >> JacobsenRG >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -- >> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >> Brian Schlining >> bschlining at gmail.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx From m.j.tandy at warwick.ac.uk Wed May 13 16:42:24 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 13 May 2009 23:42:24 +0100 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A0B40A6.5070204@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> <4A0B40A6.5070204@weru.ksu.edu> Message-ID: <302aa0340905131542i601ec3f1w3b0b5879c23f8eca@mail.gmail.com> Perhaps you could post your program, or an excerpt of it sufficient to demonstrate the problem you're having, for us to have a look at? 2009/5/13 Bill Rust : > Tod's solution misses the point. He is picking and opening the serial > port. That's the step before where my problem occurs. > > To recap: > > 1. I have a simple java swing app. > 2. On the menu bar, there is the standard set, file, etc., of jmenu's. > Under file, there is a jmenuitem, logfileopen, which pops up a > jfilechooser to select a logfile and another jmenuitem, setprefix, which > pops up a jdialog to allow the user to type in a file name prefix for > downloaded images. > 3. There is another jmenuitem that starts the commport running. > 4. When logfileopen is pressed before the commport is started, it works. > 5. When logfileopen is pressed after the commport is started, it hangs. > 6. setprefix works whether or not the commport is started. > 7. portIdentifier.open starts a thread that goes into a native > method, ? ? ? ? ? ? ? ? ? ? ? ? RXTXPort.eventLoop, and never returns. > 8. java.sun bugs has a bug report, 6741890, that is similar but > their ? ? ? ? ? ? ? ? ? workaround doesn't. > 9. When it locks up, there is a swing-shell thread that appears to be > ? ? ? ?down in some native libraries, winshellfolder2 > 10. The awt-eventQ thread is unblocked but in code that says its parked. > > If you have anymore ideas, I'd really appreciate them. > > wjr > > Tod E. Kurt wrote: >> This is the exact technique I use to let the user choose which serial >> port to use on startup. ?Here's a method I've got in many of my sketches: >> >> void choosePort() { >> ? String portlist[] = Serial.list(); >> ? String port = null; >> ? javax.swing.SwingUtilities.invokeLater(new Runnable() { >> ? ? public void run() { >> ? ? ? try { >> ? ? ? ? String port = (String) javax.swing.JOptionPane.showInputDialog( >> null, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Select Serial Port", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "MySuperSketch", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? javax.swing.JOptionPane.QUESTION_MESSAGE, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? null, portlist, null); >> ? ? ? ? if( port == null ) ?{ >> ? ? ? ? ? javax.swing.JOptionPane.showMessageDialog(null, "No port >> chosen, goodbye"); >> ? ? ? ? ? System.exit(1); >> ? ? ? ? } >> ? ? ? ? serialPort = port; >> ? ? ? } >> ? ? ? catch (Exception e) { >> ? ? ? ? e.printStackTrace(); >> ? ? ? } >> ? ? } >> ? } ); >> } >> >> >> On May 8, 2009, at 2:08 p, Brian Schlining wrote: >> >>> Bob's probably right...take look at javax.swing.SwingUtilites for the >>> workaround to get your swing stuff invoked on the EventDispatchThread >>> (EDT). Some swing-methods do work when called outside of the EDT, but >>> just to be safe, do your creation and swing calls on the EDT. It's >>> really simple, here's an example of a synchronous call. >>> >>> // Here's how to run stuff on the EDT from a different thread >>> SwingUtilities.invokeAndWait(new Runnable() { >>> ? ? ? public void run() { >>> ? ? ? ? ? ?JFileChooser fc; // create, setup, show your filechooser >>> ? ? ? ? ? ?// Get the result from the filechooser >>> ? ? ? } >>> }); >>> >>> To do a asynchronous call use SwingUtilities.invokeLater >>> >>> >>> >I wrote a small swing app to download images from an industrial camera. >>> >I used the two way serial sample code as a starting point. The app works >>> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >>> >then try to change the output directory or log file, the jfilechooser >>> >winds up trying to unpark (note, parking is not something I'm really >>> >familiar with) and doesn't. >>> What is the threading structure of your code? >>> >>> The various high-function Swing components, such as JFileChooser, are >>> notorious for doing Really Bad Stuff when invoked from off the Swing >>> thread. >>> >>> Bob >>> -- >>> Bob Jacobsen, UC Berkeley >>> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >>> JacobsenRG >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >>> -- >>> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >>> Brian Schlining >>> bschlining at gmail.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From m.j.tandy at warwick.ac.uk Thu May 14 03:05:36 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 14 May 2009 10:05:36 +0100 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A0B40A6.5070204@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> <4A0B40A6.5070204@weru.ksu.edu> Message-ID: <302aa0340905140205p6ceb5a9br24e00a50e9cafa5@mail.gmail.com> Java has a built in deadlock detection utility; run your program from the command line, then (on windows) press Ctrl+Break (On Linux, Ctrl+\ does the trick I'm told). That should produce status information and a stack trace for every running thread, including locks held and locks waited on. Maybe that would contain enough information for you to work out what's locking what? 2009/5/13 Bill Rust : > Tod's solution misses the point. He is picking and opening the serial > port. That's the step before where my problem occurs. > > To recap: > > 1. I have a simple java swing app. > 2. On the menu bar, there is the standard set, file, etc., of jmenu's. > Under file, there is a jmenuitem, logfileopen, which pops up a > jfilechooser to select a logfile and another jmenuitem, setprefix, which > pops up a jdialog to allow the user to type in a file name prefix for > downloaded images. > 3. There is another jmenuitem that starts the commport running. > 4. When logfileopen is pressed before the commport is started, it works. > 5. When logfileopen is pressed after the commport is started, it hangs. > 6. setprefix works whether or not the commport is started. > 7. portIdentifier.open starts a thread that goes into a native > method, ? ? ? ? ? ? ? ? ? ? ? ? RXTXPort.eventLoop, and never returns. > 8. java.sun bugs has a bug report, 6741890, that is similar but > their ? ? ? ? ? ? ? ? ? workaround doesn't. > 9. When it locks up, there is a swing-shell thread that appears to be > ? ? ? ?down in some native libraries, winshellfolder2 > 10. The awt-eventQ thread is unblocked but in code that says its parked. > > If you have anymore ideas, I'd really appreciate them. > > wjr > > Tod E. Kurt wrote: >> This is the exact technique I use to let the user choose which serial >> port to use on startup. ?Here's a method I've got in many of my sketches: >> >> void choosePort() { >> ? String portlist[] = Serial.list(); >> ? String port = null; >> ? javax.swing.SwingUtilities.invokeLater(new Runnable() { >> ? ? public void run() { >> ? ? ? try { >> ? ? ? ? String port = (String) javax.swing.JOptionPane.showInputDialog( >> null, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Select Serial Port", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "MySuperSketch", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? javax.swing.JOptionPane.QUESTION_MESSAGE, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? null, portlist, null); >> ? ? ? ? if( port == null ) ?{ >> ? ? ? ? ? javax.swing.JOptionPane.showMessageDialog(null, "No port >> chosen, goodbye"); >> ? ? ? ? ? System.exit(1); >> ? ? ? ? } >> ? ? ? ? serialPort = port; >> ? ? ? } >> ? ? ? catch (Exception e) { >> ? ? ? ? e.printStackTrace(); >> ? ? ? } >> ? ? } >> ? } ); >> } >> >> >> On May 8, 2009, at 2:08 p, Brian Schlining wrote: >> >>> Bob's probably right...take look at javax.swing.SwingUtilites for the >>> workaround to get your swing stuff invoked on the EventDispatchThread >>> (EDT). Some swing-methods do work when called outside of the EDT, but >>> just to be safe, do your creation and swing calls on the EDT. It's >>> really simple, here's an example of a synchronous call. >>> >>> // Here's how to run stuff on the EDT from a different thread >>> SwingUtilities.invokeAndWait(new Runnable() { >>> ? ? ? public void run() { >>> ? ? ? ? ? ?JFileChooser fc; // create, setup, show your filechooser >>> ? ? ? ? ? ?// Get the result from the filechooser >>> ? ? ? } >>> }); >>> >>> To do a asynchronous call use SwingUtilities.invokeLater >>> >>> >>> >I wrote a small swing app to download images from an industrial camera. >>> >I used the two way serial sample code as a starting point. The app works >>> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >>> >then try to change the output directory or log file, the jfilechooser >>> >winds up trying to unpark (note, parking is not something I'm really >>> >familiar with) and doesn't. >>> What is the threading structure of your code? >>> >>> The various high-function Swing components, such as JFileChooser, are >>> notorious for doing Really Bad Stuff when invoked from off the Swing >>> thread. >>> >>> Bob >>> -- >>> Bob Jacobsen, UC Berkeley >>> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >>> JacobsenRG >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >>> -- >>> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >>> Brian Schlining >>> bschlining at gmail.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From cowwoc at bbs.darktech.org Fri May 15 07:18:29 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 09:18:29 -0400 Subject: [Rxtx] InputStream timeouts Message-ID: <4A0D6BA5.8020209@bbs.darktech.org> Why does InputStream.read() return -1 on timeout instead of throwing InterruptedIOException which has existed specifically for this purpose since JDK 1.0? Sockets throw SocketTimeoutException which extends InterruptedIOException. I suspect that this logic confuses BufferedInputStream as well as end-users. Can we introduce this change along with the other timeout-related changes? Gili From Steffen.DETTMER at ingenico.com Fri May 15 07:36:19 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 15 May 2009 15:36:19 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0D6BA5.8020209@bbs.darktech.org> References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <20090515133619.GC17036@elberon.bln.de.ingenico.com> * cowwoc wrote on Fri, May 15, 2009 at 09:18 -0400: > Why does InputStream.read() return -1 on timeout shouldn't it block and only avialable() should care about timeouts? That is how I understand `This method blocks until input data is available' from: http://java.sun.com/j2se/1.5.0/docs/api/java/io/InputStream.html#read() public abstract int read() throws IOException Reads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. A subclass must provide an implementation of this method. Returns: the next byte of data, or -1 if the end of the stream is reached. Throws: IOException - if an I/O error occurs. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Fri May 15 08:22:19 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 15 May 2009 17:22:19 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: >From the javadoc for InputStream: "If no byte is available because the end of the stream has been reached, the value -1 is returned." Since character timeout is not an indication of EOF condition I guess one could argue that 0 should be returned in case of timeout. On the other hand one could also argue that since no data was available (if it timed out) the serial port input stream was at the end of stream (albeit possibly temporarily only). Further the javadoc seems to forbid the return value 0 for Inputstream.read(): " This method blocks until input data is available, the end of the stream is detected, or an exception is thrown." So it can return n >= 1 , -1 or throw an exception. InputStream.read(byte[]) can return 0 but for consistency the options with the other read methods the return value for timeout needs to be -1 or an exception. It goes against my grain to think that I get an exception when I've set up a timeout and I am thus expecting a timeout to happen sometimes. So it is not an exceptional case but expected situation in which case a special return value is philosophically speaking more appropriate. So I'm against changing this behavior. I expect a lot of code depend on the -1 or at least on not getting an exception when a timeout occurs. In any case if an exception were to be thrown it should *not* be InterruptedIOException. >From the javadoc for InterruptedIOException: "An InterruptedIOException is thrown to indicate that an input or output transfer has been terminated because the thread performing it was interrupted. The field bytesTransferred indicates how many bytes were successfully transferred before the interruption occurred" I do not think this matches the case for serial port receive character timeout. I read the javadoc above so that I get this exception when the thread in my code that is performing a read or write operation gets interrupted by Thread.interrupt(). And this is used to handle exactly that case: being able to gracefully and cleanly interrupt threads. my 2 snt worth br Kusti > From: cowwoc > Date: Fri, 15 May 2009 16:18:29 +0300 > To: rxtx > Conversation: [Rxtx] InputStream timeouts > Subject: [Rxtx] InputStream timeouts > > > > Why does InputStream.read() return -1 on timeout instead of > throwing InterruptedIOException which has existed specifically for this > purpose since JDK 1.0? Sockets throw SocketTimeoutException which > extends InterruptedIOException. I suspect that this logic confuses > BufferedInputStream as well as end-users. Can we introduce this change > along with the other timeout-related changes? > > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From cowwoc at bbs.darktech.org Fri May 15 08:35:27 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 10:35:27 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <4A0D7DAF.5030705@bbs.darktech.org> I disagree with your interpretation. Read SocketTimeoutException to see what I mean. InterruptedIOException means the operation was interrupted, not necessarily by way of Thread.interrupt(). Returning 0 in case of timeout sounds wrong to me because it is a legal byte value that could have been read. Returning -1 also sounds wrong to me because this isn't strictly the end of stream. BufferedInputStream and others assume that once you reach the end of stream you will never see more data, ever. As far as I know, the core APIs are written in terms of throwing InterruptedIOException for timeouts. Gili Kustaa Nyholm wrote: > >>From the javadoc for InputStream: > > "If no byte is available because the end of the stream has been reached, the > value -1 is returned." > > > Since character timeout is not an indication of EOF condition I guess one > could argue that 0 should be returned in case of timeout. On the other hand > one could also argue that since no data was available (if it timed out) the > serial port input stream was at the end of stream (albeit possibly > temporarily only). Further the javadoc seems to forbid the return value 0 > for Inputstream.read(): > > " This method blocks until input data is available, the end of the stream is > detected, or an exception is thrown." > > So it can return n >= 1 , -1 or throw an exception. InputStream.read(byte[]) > can return 0 but for consistency the options with the other read methods the > return value for timeout needs to be -1 or an exception. > > It goes against my grain to think that I get an exception when I've set up a > timeout and I am thus expecting a timeout to happen sometimes. So it is not > an exceptional case but expected situation in which case a special return > value is philosophically speaking more appropriate. > > So I'm against changing this behavior. I expect a lot of code depend on the > -1 or at least on not getting an exception when a timeout occurs. > > In any case if an exception were to be thrown it should *not* be > InterruptedIOException. > >>From the javadoc for InterruptedIOException: > > > "An InterruptedIOException is thrown to indicate that an input or output > transfer has been terminated because the thread performing it was > interrupted. The field bytesTransferred indicates how many bytes were > successfully transferred before the interruption occurred" > > I do not think this matches the case for serial port receive character > timeout. I read the javadoc above so that I get this exception when the > thread in my code that is performing a read or write operation gets > interrupted by Thread.interrupt(). And this is used to handle exactly that > case: being able to gracefully and cleanly interrupt threads. > > > > my 2 snt worth br Kusti > > > > >> From: cowwoc >> Date: Fri, 15 May 2009 16:18:29 +0300 >> To: rxtx >> Conversation: [Rxtx] InputStream timeouts >> Subject: [Rxtx] InputStream timeouts >> >> >> >> Why does InputStream.read() return -1 on timeout instead of >> throwing InterruptedIOException which has existed specifically for this >> purpose since JDK 1.0? Sockets throw SocketTimeoutException which >> extends InterruptedIOException. I suspect that this logic confuses >> BufferedInputStream as well as end-users. Can we introduce this change >> along with the other timeout-related changes? >> >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From m.j.tandy at warwick.ac.uk Fri May 15 09:17:36 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Fri, 15 May 2009 16:17:36 +0100 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <302aa0340905150817o39812d7y1b896004a2dcc2ab@mail.gmail.com> > I disagree with your interpretation. Read SocketTimeoutException to see > what I mean. InterruptedIOException means the operation was interrupted, > not necessarily by way of Thread.interrupt(). Strangely enough, the javadoc for InterruptedIOException says: "An InterruptedIOException is thrown to indicate that an input or output transfer has been terminated because the thread performing it was interrupted."[1] But the subclass SocketTimeoutException is used differently - here's an example from sun.net.httpserver.request: /** * block() only called when available==0 and buf is empty */ private synchronized void block () throws IOException { long currtime = server.getTime(); long maxtime = currtime + readTimeout; while (currtime < maxtime) { if (selector.select (readTimeout) == 1) { selector.selectedKeys().clear(); available (); return; } currtime = server.getTime(); } throw new SocketTimeoutException ("no data received"); } So it seems that SocketTimeoutExceptions get thrown not upon thread interruptions, but a certain time after a blocking read is started. [1] http://java.sun.com/javase/6/docs/api/java/io/InterruptedIOException.html From cowwoc at bbs.darktech.org Fri May 15 11:06:53 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 13:06:53 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0DA0F4.9050203@bbs.darktech.org> References: <4A0DA0F4.9050203@bbs.darktech.org> Message-ID: <4A0DA12D.2050303@bbs.darktech.org> Forgot to CC the list. Gili cowwoc wrote: > > "Thread was interrupted" does not necessarily mean > Thread.interrupt(). It just means that the operation (run by the thread) > was interrupted. If you read the beginning sentence for > InterruptedIOException it reads "Signals that an I/O operation has been > interrupted". This says nothing about the thread itself. Michael's > subsequent post about SocketTimeoutException reinforces that point. > > By the way, I think that in general you need to interpret the > Javadoc for core classes in a broader sense than it seems. Older Javadoc > (from version 1.0) used to mention implementation details that were not > necessarily important and limited the applicability of the classes. > Newer documentation tends to go out of its way to avoid mentioning such > implementation detail and I believe that's a good thing. When > InterruptedIOException was written, Thread.interrupt() was probably the > only way to interrupt I/O operations. Nowadays there are others. Sun has > generalized its meaning over time as evident by SocketTimeoutException. > At least, that's my interpretation :) > > Gili > > Kustaa Nyholm wrote: >>> I disagree with your interpretation. Read >>> SocketTimeoutException to >>> see >>> what I mean. InterruptedIOException means the operation was interrupted, >>> not necessarily by way of Thread.interrupt(). >> >> Well SocketTimeoutException javadoc only says, very briefly: >> >> "Signals that a timeout has occurred on a socket read or accept." >> >> So that is not too helpful. But since it is derived from >> InterruptedIOException my interpretation it that they have an 'is-a' >> relationship and InterruptedIOException needs to honor the contract of >> InterruptedIOException which says: >> >> "...because the thread performing it was interrupted." >> >> To me this very specifically talks about interrupting threads with >> Thread.interrupt() >> >> >>> Returning 0 in case of timeout sounds wrong to me because it >>> is a >>> legal >>> byte value that could have been read. >> Agreed, that's what I tried to say. 0 is a legal byte value for read() to >> return so that cannot be used. For read read(byte[]) which returns the >> number of bytes read 0 could be used but there again 0 can be returned >> if 0 >> byte[] size is 0. So there again 0 is not a good option. >> >>> Returning -1 also sounds wrong to >>> me because this isn't strictly the end of stream. >> Like I said, it isn't strictly the end of stream. But also does not >> forbid treating it as (temporary) end of stream. >> >>> BufferedInputStream >>> and others assume that once you reach the end of stream you will never >>> see more data, ever. >> Can you provide a reference for that. >> >>> As far as I know, the core APIs are written in >>> terms of throwing InterruptedIOException for timeouts. >> Would also like to see something to support that. >> >> >> The behavior of throwing an exception on timeout is also a little bit >> problematic, consider: >> >> byte buf[1000]; >> int n=ins.read(buf); >> // do something with the n bytes received >> >> What happens if a timeout occurs before we have received 1000 bytes? >> >> If an exception is thrown then the user of the read() needs to handle >> the bytes received in two places or else those last <1000 bytes are lost. >> A better solution would be to return the bytes received so far and throw >> the exception on the next call (if any). But the main point is that >> neither of these case obviously correct and neither is specified in the >> javadocs. Where as a lot of code that just handles the return value >> of read(byte[]) correctly works without any further ado. >> >> >> >> The main thing is that I think we should not break existing applications, >> which I expect are not handling InterruptedIOException but many of >> which may >> depend on getting back -1 in case of timeouts. >> >> It has been a while since I used the javax.javacomm but I seem to recall >> that it returned -1 and I think this is the defining standard. >> >> I expect most rxtx users are more interested in compatibility and >> stability >> than semantic niceties and improving the API. >> >> br Kusti >> >> >> > From johnny.luong at trustcommerce.com Fri May 15 13:16:15 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Fri, 15 May 2009 12:16:15 -0700 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0DA12D.2050303@bbs.darktech.org> References: <4A0DA0F4.9050203@bbs.darktech.org> <4A0DA12D.2050303@bbs.darktech.org> Message-ID: <4A0DBF7F.50808@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 cowwoc wrote: | Forgot to CC the list. | | Gili | | cowwoc wrote: |> "Thread was interrupted" does not necessarily mean |> Thread.interrupt(). It just means that the operation (run by the thread) |> was interrupted. If you read the beginning sentence for |> InterruptedIOException it reads "Signals that an I/O operation has been |> interrupted". This says nothing about the thread itself. Michael's |> subsequent post about SocketTimeoutException reinforces that point. |> |> By the way, I think that in general you need to interpret the |> Javadoc for core classes in a broader sense than it seems. Older Javadoc |> (from version 1.0) used to mention implementation details that were not |> necessarily important and limited the applicability of the classes. |> Newer documentation tends to go out of its way to avoid mentioning such |> implementation detail and I believe that's a good thing. When |> InterruptedIOException was written, Thread.interrupt() was probably the |> only way to interrupt I/O operations. Nowadays there are others. Sun has |> generalized its meaning over time as evident by SocketTimeoutException. |> At least, that's my interpretation :) |> |> Gili |> |> Kustaa Nyholm wrote: |>>> I disagree with your interpretation. Read |>>> SocketTimeoutException to |>>> see |>>> what I mean. InterruptedIOException means the operation was interrupted, |>>> not necessarily by way of Thread.interrupt(). |>> Well SocketTimeoutException javadoc only says, very briefly: |>> |>> "Signals that a timeout has occurred on a socket read or accept." |>> |>> So that is not too helpful. But since it is derived from |>> InterruptedIOException my interpretation it that they have an 'is-a' |>> relationship and InterruptedIOException needs to honor the contract of |>> InterruptedIOException which says: |>> |>> "...because the thread performing it was interrupted." |>> |>> To me this very specifically talks about interrupting threads with |>> Thread.interrupt() |>> |>> |>>> Returning 0 in case of timeout sounds wrong to me because it |>>> is a |>>> legal |>>> byte value that could have been read. |>> Agreed, that's what I tried to say. 0 is a legal byte value for read() to |>> return so that cannot be used. For read read(byte[]) which returns the |>> number of bytes read 0 could be used but there again 0 can be returned |>> if 0 |>> byte[] size is 0. So there again 0 is not a good option. |>> |>>> Returning -1 also sounds wrong to |>>> me because this isn't strictly the end of stream. |>> Like I said, it isn't strictly the end of stream. But also does not |>> forbid treating it as (temporary) end of stream. |>> |>>> BufferedInputStream |>>> and others assume that once you reach the end of stream you will never |>>> see more data, ever. |>> Can you provide a reference for that. |>> |>>> As far as I know, the core APIs are written in |>>> terms of throwing InterruptedIOException for timeouts. |>> Would also like to see something to support that. |>> |>> |>> The behavior of throwing an exception on timeout is also a little bit |>> problematic, consider: |>> |>> byte buf[1000]; |>> int n=ins.read(buf); |>> // do something with the n bytes received |>> |>> What happens if a timeout occurs before we have received 1000 bytes? |>> |>> If an exception is thrown then the user of the read() needs to handle |>> the bytes received in two places or else those last <1000 bytes are lost. |>> A better solution would be to return the bytes received so far and throw |>> the exception on the next call (if any). But the main point is that |>> neither of these case obviously correct and neither is specified in the |>> javadocs. Where as a lot of code that just handles the return value |>> of read(byte[]) correctly works without any further ado. |>> |>> |>> |>> The main thing is that I think we should not break existing applications, |>> which I expect are not handling InterruptedIOException but many of |>> which may |>> depend on getting back -1 in case of timeouts. |>> |>> It has been a while since I used the javax.javacomm but I seem to recall |>> that it returned -1 and I think this is the defining standard. |>> |>> I expect most rxtx users are more interested in compatibility and |>> stability |>> than semantic niceties and improving the API. |>> |>> br Kusti |>> |>> |>> | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi, Maybe a better approach (improving the API) would be to consider implementing a NIO interface atop the underlying serial communication... ~ if someone desires the existing behavior, then they use a facade that lies atop of the NIO and provide the same quirks associated with it. As I see it, the implementation overrides the general contract of the InputStream to provide for the timeout functionality and it would be somewhat troublesome to expect a user of that API to catch subclasses of IOException. Best, Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoNv38ACgkQnQTBLXttTeWZ+wCeO4CTrI5l+vLPrjHl8fBj7FOL Ft8AnjQ7bXnvMhOlwZdK5CYAuoQeQ9u0 =QAax -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon May 18 03:49:50 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 11:49:50 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <20090518094950.GG17036@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, May 15, 2009 at 17:22 +0300: > >From the javadoc for InputStream: > > Since character timeout is not an indication of EOF condition I > guess one could argue that 0 should be returned in case of > timeout. A blocking operation logically has no timeout. It is blocking. Forever, until EOF or an error. This IMHO renders usage of read() useless and read(byte[]) must be used (or no InputStream). > On the other hand one could also argue that since no data was > available (if it timed out) IMHO, read() must not time out. What would happen with a small simple console app that is relying that InputStream is implemented as required by specification? It cannot tell `no byte was received but this is not an error, please call me again' - and why should it? I think, if this is not suited, i.e. if the application may want a byte but also may not want a byte, no blocking function must be invoked, but a select must be called instead or, if no select-style function is avialable, polling must be used. This is the InputStream way (block or poll). For streams the `may or may not want a byte' may sound unlikely, but in practice this is what happens, for instance, if there is some CANCEL button in a GUI or so. Closing the stream often also is no option because it cannot be reopend but it might be needed again later. In classic unix apps often signals were used (read(2) can return EINTR), but in Java this isn't possible AFAIK. EINTR IMHO has not much relation to InterruptedIOException and I think InterruptedIOException cannot be `enforced' without doing harm. > It goes against my grain to think that I get an exception when > I've set up a timeout yeah, I thought the same and when I hit this InputStream the first time I though: ohh, a bug. Or a bunch of :-) As specified, InputStream has no timeout. If you set a timeout, then somewhere else (e.g. a sub class). In this case, the sub class should also offer a way to wait for this timeout (e.g. a select style function). In practice, this makes not much sense, leaving the options not to use it at all (but what else then?) or to violate the specification. Unfortunately it seems that subclasses add setTimeout but no select() or tryRead() or simply a available()-style with a timeout parameter. Then applications would simply use this subclasses. In practice, then it does not help that they derive InputStream at all, so personally I think they should not derive from it but instead define something with a meaning :-) But I think in practice, for read(byte[]) returning 0 (e.g. in case of [intercharacter] timeout) for many people seems straightforward - so this is probably what most people will expect. (an interesting question is how those bugs happend to the Java guys, because those topics are well known since ages and solved, for instance, in the BSD socket API, but probably they didn't know it. It took years but now it seems they understood and tried it again by some NIO which is more in the `usual way'. Next version might be usable - I wouldn't be surprised if this one then is BSD socket API alike :-) SCNR). So in practice I think: - don't use read() but read(byte[]) or read(byte[], int, int) - handle `0 bytes read' situation - polling avialable() in practice may often not be suited because avialable() has no timeout parameter and if response time is important, small polling intervals would be needed which generate load - try to avoid using InputStream (from applications) directly because it sucks and it is /not/ generic (implementations may interpret it differently because it MUST be interpreted because the specification makes not much sense in many cases) - IOException and InterruptedIOException are for I/O error situations. Additionally I think, InterruptedIOException.bytesTransferred cannot be reliable because there are cases where the OS cannot surely know this and thus cannot tell it the JVM also, peer may have not received them even if they were sent As far as I know this is exactly what rxtx is doing. When having many clients this require many threads and might be less performant, so best is not to have one thousand serial ports :-) Returning 0 here IMHO also is the only option that does not `directly' violate the spec. It tells `there is an attempt to read at least one byte.' so someone could argue that the dear computer `attempted but found no time to do so' :-) > So I'm against changing this behavior. I expect a lot of code > depend on the -1 or at least on not getting an exception when a > timeout occurs. Yes, I agree, -1 means End of file (or closed by peer) and exceptions are for errors. If exceptions should be added I think it could be made configurable. For instance by some Rs232InputStream.enableException(IOException e), store this exception and later if (e != null) throw e.clone() or so. > I do not think this matches the case for serial port receive character > timeout. I read the javadoc above so that I get this exception when the > thread in my code that is performing a read or write operation gets > interrupted by Thread.interrupt(). And this is used to handle exactly that > case: being able to gracefully and cleanly interrupt threads. (well, I think Thread.interrupt() also is a big topic on its own and I'm afraid there is no really reliable mechanism for `cleanly interrupt threads' and maybe even that logically threads cannot be interrupted cleanly at all) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From rxtx at qbang.org Mon May 18 05:17:08 2009 From: rxtx at qbang.org (VIAGRA ® Official Site) Date: Mon, 18 May 2009 05:17:08 -0600 Subject: [Rxtx] DISCOUNT ID42992 75% 0FF on Pfizer ! Message-ID: <200905181117.n4IBH8ku024296@rxtx.qbang.org> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/4c172d08/attachment-0007.html From Kustaa.Nyholm at planmeca.com Mon May 18 07:20:40 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 18 May 2009 16:20:40 +0300 Subject: [Rxtx] InputStream timeouts Message-ID: Oops, sorry sent this to Steffen directly instead of mailing list. So here for the list: > A blocking operation logically has no timeout. It is blocking. > Forever, until EOF or an error. This IMHO renders usage of read() > useless and read(byte[]) must be used (or no InputStream). This is true, however read(byte[]) too is blocking so logically that (allowing it to return with value 0 in case of timeout) is no better (or worse) than read(). According to InputsStream javadoc only when byte[].length is 0 is read(byte[]) non blocking and can return 0. But to be clear: I'm in favor of returning 0 in case of timeouts for read(byte[]) and -1 for read(). > >> On the other hand one could also argue that since no data was >> available (if it timed out) > > IMHO, read() must not time out. IMHO read() should behave consistently with respect to the other read(...) methods. If we allow them to timeout, we should also allow read() to timeout. And in that case we need a return value that separates that case from normal return value (0-255), so -1 seems like a good candidate. > What would happen with a small > simple console app that is relying that InputStream is > implemented as required by specification? It cannot tell `no byte > was received but this is not an error, please call me again' > - and why should it? I think that the simple console app would be just fine, because timeouts are disabled by default so the simple applications are not affected. > > In practice, this makes not much sense, leaving the options not > to use it at all (but what else then?) or to violate the > specification. The javadoc for CommPort.getInputStream() spells out the rules for timeouts: http://java.sun.com/products/javacomm/reference/api/javax/comm/CommPort.html #getInputStream() So, IMO, while it is interesting to discuss these things the javacomm specs is quite clear about blocking behavior and although there is some conflict between how (file) inputstream behaves and Commport inputstreams behave, I think rxtx should adhere to the javacomm spec. > But I think in practice, for read(byte[]) returning 0 (e.g. in > case of [intercharacter] timeout) for many people > seems straightforward - so this is probably what most people will > expect. Agreed, I'm 100% sure there are lots of people out there that use timeouts and depend on the current behavior. Changing this would not help them but infuriate them. > > (well, I think Thread.interrupt() also is a big topic on its own > and I'm afraid there is no really reliable mechanism for > `cleanly interrupt threads' and maybe even that logically > threads cannot be interrupted cleanly at all) Would be interesting to discuss that too but that is beyond the topic of this thread. However I still believe that the InterruptedIOException was introduced so that blocking IO calls could gracefully 'return' if the calling thread was interrupted. Weather this is reliable or clean or graceful could be discussed but to me it seem reasonable. If you have a thread that is blocking on some I/O we need a mechanism that allows stopping that thread in a controlled manner and InterruptedIOException seems to provide this. cheers Kusti From Steffen.DETTMER at ingenico.com Mon May 18 09:18:37 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 17:18:37 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <20090518151837.GS17036@elberon.bln.de.ingenico.com> [OT] * Kustaa Nyholm wrote on Mon, May 18, 2009 at 16:20 +0300: > > A blocking operation logically has no timeout. It is blocking. > > Forever, until EOF or an error. This IMHO renders usage of read() > > useless and read(byte[]) must be used (or no InputStream). > This is true, however read(byte[]) too is blocking so logically that > (allowing it to return with value 0 in case of timeout) is no better > (or worse) than read(). According to InputsStream javadoc only when > byte[].length is 0 is read(byte[]) non blocking and can return 0. I think the essential difference is that for read(byte[]) returning 0 is somewhat clear, but for read() 0 is a valid byte and thus it would be a horrible mess to also use it for timeouts :) > >> On the other hand one could also argue that since no data was > >> available (if it timed out) > > > > IMHO, read() must not time out. > > IMHO read() should behave consistently with respect to the > other read(...) methods. If we allow them to timeout, we should > also allow read() to timeout. And in that case we need a return > value that separates that case from normal return value (0-255), > so -1 seems like a good candidate. Well, but then this is not consistently to EOF handling... (and if read() cannot be consistent, maybe not using it at all is an option?) > > What would happen with a small simple console app that is > > relying that InputStream is implemented as required by > > specification? It cannot tell `no byte was received but this > > is not an error, please call me again' - and why should it? > I think that the simple console app would be just fine, because > timeouts are disabled by default so the simple applications are > not affected. Not setting timeouts IMHO does not mean no timeouts will be applied but that some default timeout is used instead, which could be infinite or some OS value, which in turn may be configurable (like the TCP wait timeouts). > > In practice, this makes not much sense, leaving the options not > > to use it at all (but what else then?) or to violate the > > specification. > > The javadoc for CommPort.getInputStream() spells out the rules for > timeouts: > > http://java.sun.com/products/javacomm/reference/api/javax/comm/CommPort.html > #getInputStream() > So, IMO, while it is interesting to discuss these things > the javacomm specs is quite clear about blocking behavior > and although there is some conflict between how (file) inputstream > behaves and Commport inputstreams behave, I think rxtx should > adhere to the javacomm spec. I think first this does not clearly state what happens a read caller when a timeout occures and second IMHO it does violate the InputStream specification contract (API/javadoc). Formally speaking, it is a bug :-) Also those `advisory methods' in a formal interface are bad, I think. But another topic and discussed already several times :) Yes, in the end it seems the clear correct possiblity (no timeouts) makes no sense, so something pragmatic is needed :-) > > But I think in practice, for read(byte[]) returning 0 (e.g. in > > case of [intercharacter] timeout) for many people > > seems straightforward - so this is probably what most people will > > expect. > Agreed, I'm 100% sure there are lots of people out there that > use timeouts and depend on the current behavior. Changing this > would not help them but infuriate them. yeah, and when shifting to another type of InputStream suddenly they may break, rendering that interface a bit useless, but this is all we have... Correct IMHO would be that the compiler is able to check whether an interface supports timeouts or not (i.e. all methods exist and work as specified or a different interface must be used. Lets say we would have InputStream and InputStreamTimeout or whatever, there would be so many possibilities, but most with own disadvantages). Well, I wonder why they did not even add a timeout parameter to available() and why they forgot about write timeouts completely (also there is no counterpart to available()). Anyway. > > (well, I think Thread.interrupt() also is a big topic on its own > > and I'm afraid there is no really reliable mechanism for > > `cleanly interrupt threads' and maybe even that logically > > threads cannot be interrupted cleanly at all) > Would be interesting to discuss that too but that is beyond the > topic of this thread. However I still believe that the > InterruptedIOException was introduced so that blocking > IO calls could gracefully 'return' if the calling thread > was interrupted. Yes, maybe they forgot it in first place, then found that read can throw IOExceptions only and thus invented InterruptedIOException for InterruptedException-alike cases? but anyway. > Weather this is reliable or clean or graceful could be > discussed but to me it seem reasonable. (With not reliable I mean, when for instance you wanted to write 10 byte and you get this exception telling 5 byte have been written, you cannot be sure what this means. Maybe the 6th byte is in a fifo or whatever. I think best is to avoid the need to handle this). > If you have a thread that is blocking on some I/O we need a > mechanism that allows stopping that thread in a controlled > manner and InterruptedIOException seems to provide this. I think also this is not reliable, because even if the JVM knows a thread is supposed to be `killed', I see at least two issues: first is that native code may be active and cannot be forced to return and second it could be that the thread would need to perform clean up tasks, and since Java does not support RAII (destructors cannot clean), at least you get in trouble when exceptions happening during this cleanup (i.e. exceptions after the thread stops). This in turn IMHO is likely to happen because a well-known situation to interrupt such a thread might be after some error, and after errors exceptions I think happen more often (because less well tested and others). Let's say the thread uses an InputStream (owned by someone else) and now discards it by calling it's close (which should be a delete - because what is an input stream which is closed? Obviously it is not an input stream anymore :-)). Now you might have a special InputStream requiring special things (it might be a protocol requiring some final quit message to be sent, it might need not to close it if used by someone else, too, additional actions may be needed). Logically this could be implemented (turing complete language :-)), but in practice it might not be possible, simply because too complex (to do it right in all circumstances). oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Mon May 18 10:02:39 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 18 May 2009 19:02:39 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: > Not setting timeouts IMHO does not mean no timeouts will be > applied but that some default timeout is used instead, which > could be infinite or some OS value, which in turn may be > configurable (like the TCP wait timeouts). > The javadoc says: "By default, receive timeout is not enabled." and "By default, receive threshold is not enabled." thus (from getInputStream javadoc): "block until any data is available" which is consistent InputStream contract. > I think first this does not clearly state what happens a read > caller when a timeout occures That is true. > and second IMHO it does violate the > InputStream specification contract (API/javadoc). Formally > speaking, it is a bug :-) Agreed, but I think given the advantages you get by using InputStream (as means of reading the serial port as opposed to coming up with some totally new Stream concept) I think this was reasonable compromise and bending of the rules. > yeah, and when shifting to another type of InputStream suddenly > they may break, rendering that interface a bit useless, but this > is all we have... Exactly. > (With not reliable I mean, when for instance you wanted to write > 10 byte and you get this exception telling 5 byte have been > written, you cannot be sure what this means. Maybe the 6th byte > is in a fifo or whatever. I think best is to avoid the need to > handle this). I think all we can assume is that at least 5 bytes have been written into the native driver, weather they are in the fifo or whatever we cannot know. But as you wrote, best avoid depending on this behaviour. > I think also this is not reliable, because even if the JVM knows > a thread is supposed to be `killed', I see at least two issues: > first is that native code may be active and cannot be forced to > return Yes, but this is sort of implementation detail, not an API or Java design issue. The JVM and system class implementations should guarantee this (I bet they don't, consistently, for all platforms and OSes). > and second it could be that the thread would need to > perform clean up tasks, and since Java does not support RAII > (destructors cannot clean), at least you get in trouble when > exceptions happening during this cleanup (i.e. exceptions after > the thread stops). I sort of see what you mean, but still I do not see how this could happen if the cleanup catches exceptions properly. But then I've not studied this in detail. > This in turn IMHO is likely to happen because > a well-known situation to interrupt such a thread might be after > some error, and after errors exceptions I think happen more often > (because less well tested and others). > > Let's say the thread uses an InputStream (owned by someone else) > and now discards it by calling it's close (which should be a > delete - because what is an input stream which is closed? > Obviously it is not an input stream anymore :-)). > Now you might have a special InputStream requiring special things > (it might be a protocol requiring some final quit message to be > sent, it might need not to close it if used by someone else, > too, additional actions may be needed). > Logically this could be implemented (turing complete language :-)), > but in practice it might not be possible, simply because too > complex (to do it right in all circumstances). Ok, I think I understand what you mean: you are saying that what mention aboce "if the cleanup catches exceptions properly" maybe be and often is too difficult/complex to implement and test properly? Yeah, seen that, been there, fallen for it... cheers Kusti From Steffen.DETTMER at ingenico.com Mon May 18 10:39:26 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 18:39:26 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: <20090518163925.GV17036@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Mon, May 18, 2009 at 19:02 +0300: > > Not setting timeouts IMHO does not mean no timeouts will be > > applied but that some default timeout is used instead, which > > could be infinite or some OS value, which in turn may be > > configurable (like the TCP wait timeouts). > > > The javadoc says: > "By default, receive timeout is not enabled." > and > "By default, receive threshold is not enabled." mmm... but they are optional, so what if a driver does not support timeouts but underlaying comm interface does? anyway, *I* would not rely (but loop) but maybe this is not needed. > > and second IMHO it does violate the > > InputStream specification contract (API/javadoc). Formally > > speaking, it is a bug :-) > Agreed, but I think given the advantages you get by using > InputStream (as means of reading the serial port as opposed > to coming up with some totally new Stream concept) I think > this was reasonable compromise and bending of the rules. I don't like InputStream at all. I think it is not an abstraction to remove and later re-add (hack in) needing things. I dislike that noone knows whether it streams bytes or chars or unicode or whatever. Also, I'm used birectional things (`all things are files') for communications, I think it is simpler. So InputStream IMHO is oversimplified. Maybe it was inspired by unix line discipline (but you can select it :-)). Who knows. Anyway. > > I think also this is not reliable, because even if the JVM knows > > a thread is supposed to be `killed', I see at least two issues: > > first is that native code may be active and cannot be forced to > > return > Yes, but this is sort of implementation detail, not an API or > Java design issue. The JVM and system class implementations should > guarantee this (I bet they don't, consistently, for all platforms > and OSes). I think when no reasonable implementation is possible, probably the design is not good. If there is no reasonable way to shutdown (kill) a thread (which is the case IMHO), it makes not much sense to design it. Instead, some mechanism would be needed. I guess the InterruptedException in fact is such a kind of mechanism. I'm not sure but I think Java itself disencourages to use it. > > and second it could be that the thread would need to > > perform clean up tasks, and since Java does not support RAII > > (destructors cannot clean), at least you get in trouble when > > exceptions happening during this cleanup (i.e. exceptions after > > the thread stops). > I sort of see what you mean, but still I do not see how this > could happen if the cleanup catches exceptions properly. But > then I've not studied this in detail. > Ok, I think I understand what you mean: you are saying that > what mention aboce "if the cleanup catches exceptions properly" > maybe be and often is too difficult/complex to implement and > test properly? Yes, since it should work for any implementation, it should work for InputStreams that call abitrary complex read operations. I have applications where the read leads to some CORBA calls to a remote C++ application which also has its complexity. Now in some finally {} exceptions can occure, for instance during member destruction (closing). For example, if you have a facade like implementation with: { old = setMyLogLevel(off); for (i=0; i Yeah, seen that, been there, fallen for it... (welcome in the club :-)) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bill7007 at gmail.com Mon May 18 11:08:45 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 18 May 2009 13:08:45 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090518151837.GS17036@elberon.bln.de.ingenico.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: I can add this thought, I think the timeout is part of a protocol, which should sit above RXTX. The main feature needed in RXTX to support a protocol using timeouts is a way to interrupt it into a known state, like a reset() function. The function should cause an exception to any associated thread that was waiting on IO, maybe a unique exception due to reset() call. An IO (as opposed to Interrupted) exception may be better since the reset() has to leave a known state which may affect IO in progress. I helped work a similar situation in a CAN bus protocol. In the protocol, a send would be followed by a wait for receive. A timeout thread was enabled which caused an "alarm" event to any registered handlers upon timeout. A receive canceled the timeout alarm. The timing and thread coordination is tricky but that is all left to the protocol code. The protocols timeout event handler reset the CAN controller to get it into a known state for a retry. The reset caused an IO exception to the waiting read thread which could check that a timeout had caused it. So, if timeout is considered part of a higher level protocol class, read and write don't need special interface features as long as there is a way for a waiting state in native code to be forced to exit in a reliable, detectable, manner. +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/c9b25045/attachment-0006.html From johnny.luong at trustcommerce.com Mon May 18 11:49:53 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 18 May 2009 10:49:53 -0700 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: <4A119FC1.3090700@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Johnson wrote: | I can add this thought, I think the timeout is part of a protocol, which | should sit above RXTX. The main feature needed in RXTX to support a protocol | using timeouts is a way to interrupt it into a known state, like a reset() | function. The function should cause an exception to any associated thread | that was waiting on IO, maybe a unique exception due to reset() call. An IO | (as opposed to Interrupted) exception may be better since the reset() has to | leave a known state which may affect IO in progress. | | I helped work a similar situation in a CAN bus protocol. In the protocol, a | send would be followed by a wait for receive. A timeout thread was enabled | which caused an "alarm" event to any registered handlers upon timeout. A | receive canceled the timeout alarm. The timing and thread coordination is | tricky but that is all left to the protocol code. The protocols timeout | event handler reset the CAN controller to get it into a known state for a | retry. The reset caused an IO exception to the waiting read thread which | could check that a timeout had caused it. | | So, if timeout is considered part of a higher level protocol class, read and | write don't need special interface features as long as there is a way for a | waiting state in native code to be forced to exit in a reliable, detectable, | manner. | | +BillJ | | | | ------------------------------------------------------------------------ | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx Hi Bill, This is all conjecture and probably a lot of work in practice, so its just a train of thought at this point (via NIO)... Supposer SerialPort were to implement a method that returned "SerialPortChannel" which worked along similar lines as a SocketChannel. ~ Then you could in practice, have a Selector object that did the timeout you described above (via a register method)... your read and write methods could block or not block and it would be a lot easier to drive multiple serial ports than what you have today. - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoRn8EACgkQnQTBLXttTeXm0gCfaua0ej3Rt0fogRR68bbEFG0Z BTwAn1s79U8ZU0yj6xcND8gyHzDmKKqq =ThWj -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon May 18 11:54:10 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 19:54:10 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: <20090518175409.GW17036@elberon.bln.de.ingenico.com> (OT) * Bill Johnson wrote on Mon, May 18, 2009 at 13:08 -0400: > I can add this thought, I think the timeout is part of a > protocol, which should sit above RXTX. Probably actually on both levels timeouts can be helpful; if there is some PPP/TCP or other full duplex multiplexing protcol I think at least it is nice to be able to read with some reasonable timeout(s). > I helped work a similar situation in a CAN bus protocol. In the > protocol, a send would be followed by a wait for receive. A > timeout thread was enabled which caused an "alarm" event to > any registered handlers upon timeout. A receive canceled the > timeout alarm. The timing and thread coordination is tricky but > that is all left to the protocol code. (this Bosch car protocol?) But if the protocol implementation knows the timeout value, wouldn't it be easier and suited better to have some way to apply it to the reads without needing multithreading? Was the implementation in Java? How to cancel the receive by the timeout alarm? Was it (protocol thread implementation) internally polling? You said later, `a way for a waiting state in native code to be forced to exit in a reliable, detectable, manner'. Sounds complicated :) Is this a generic requirement? I think, protocols often can be implemented to use InputStream (or some other interface) but also to offer the same interface (like the decorator pattern). At least when `stacking' such protocols it can become quite difficult, even if having an own thread per protocol instance. Of course heavily depends on the project and situation. Well, interesting topic :) > The protocols timeout event handler reset the CAN controller to > get it into a known state for a retry. The reset caused an IO > exception to the waiting read thread which could check that a > timeout had caused it. Ohh, the CAN controller must be reset? Though they would handle a whole frame automatically. I have no clue about this; surely it is very specific and complex. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bill7007 at gmail.com Mon May 18 12:25:19 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 18 May 2009 14:25:19 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A119FC1.3090700@trustcommerce.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <4A119FC1.3090700@trustcommerce.com> Message-ID: Hi Johnny, I think a SerialPortChannel could be a good example. It uses an underlying Socket which uses an underlying implementation to support open, timeouts, etc. As part of the implementation is where the current RXTX could come in, provided there is a way to back out of a blocking situation. +BillJ On Mon, May 18, 2009 at 1:49 PM, Johnny Luong < johnny.luong at trustcommerce.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Bill Johnson wrote: > | I can add this thought, I think the timeout is part of a protocol, which > | should sit above RXTX. > ... > > Hi Bill, > > This is all conjecture and probably a lot of work in practice, so its > just a train of thought at this point (via NIO)... > > Supposer SerialPort were to implement a method that returned > "SerialPortChannel" which worked along similar lines as a SocketChannel. > ~ Then you could in practice, have a Selector object that did the timeout > you described above (via a register method)... your read and write > methods could block or not block and it would be a lot easier to drive > multiple serial ports than what you have today. > > - -Johnny > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkoRn8EACgkQnQTBLXttTeXm0gCfaua0ej3Rt0fogRR68bbEFG0Z > BTwAn1s79U8ZU0yj6xcND8gyHzDmKKqq > =ThWj > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/0a44a920/attachment-0006.html From lyon at docjava.com Mon May 18 13:18:53 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 18 May 2009 15:18:53 -0400 Subject: [Rxtx] image capture In-Reply-To: References: Message-ID: Hi All, I know this is off-topic, but we have so many native method interface experts here, I just had to ask; Is anyone able to do image capture on a 64 bit mac, using Java? QT4J is not loadable using Java 6 (AFAIK). Thanks! - Doug From bill7007 at gmail.com Mon May 18 13:24:04 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 18 May 2009 15:24:04 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090518175409.GW17036@elberon.bln.de.ingenico.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> Message-ID: On Mon, May 18, 2009 at 1:54 PM, Steffen DETTMER < Steffen.DETTMER at ingenico.com> wrote: > (OT) > > * Bill Johnson wrote on Mon, May 18, 2009 at 13:08 -0400: > > I can add this thought, I think the timeout is part of a > > protocol, which should sit above RXTX. > > Probably actually on both levels timeouts can be helpful; if > there is some PPP/TCP or other full duplex multiplexing protcol I > think at least it is nice to be able to read with some reasonable > timeout(s). I think timeout at the native level does not fit well with a read() concept of timeout because it depends on the protocol not really on the read(). > > > I helped work a similar situation in a CAN bus protocol. In the > > protocol, a send would be followed by a wait for receive. A > > timeout thread was enabled which caused an "alarm" event to > > any registered handlers upon timeout. A receive canceled the > > timeout alarm. The timing and thread coordination is tricky but > > that is all left to the protocol code. > > (this Bosch car protocol?) > > But if the protocol implementation knows the timeout value, > wouldn't it be easier and suited better to have some way to apply > it to the reads without needing multithreading? > If you are waiting on a read and you are waiting on a timeout at the same time, that is two logical threads. Maybe you are looping check for one of two condition, character or timeout, but I think its the same logically as waiting for a character or a timeout exception. It is a special case where you try to read except if it take too long, sound a little like code? > Was the implementation in Java? How to cancel the receive by the > timeout alarm? Was it (protocol thread implementation) internally > polling? > The CAN bus was Java on a TINI embedded system for a warehouse system. It implemented a guaranteed delivery data path patterned after the Datagram interface, I called it a Cangram :-) The problem was how to cancel a read as part of a detected protocol or controller error. The hardware was reset via the native code driver which released resources so a restart was successful. I may have garbaged a thread and started a new one as part of it. > > You said later, `a way for a waiting state in native code to > be forced to exit in a reliable, detectable, manner'. Sounds > complicated :) Is this a generic requirement? I think, protocols > often can be implemented to use InputStream (or some other > interface) but also to offer the same interface (like the > decorator pattern). At least when `stacking' such protocols it > can become quite difficult, even if having an own thread per > protocol instance. Of course heavily depends on the project and > situation. Well, interesting topic :) > I think it (reset, stop, interrupt, whatever) should be a general requirement for any Java native interface code. Without it, your application can lock up and there is no reasonable way to regain control. > > The protocols timeout event handler reset the CAN controller to > > get it into a known state for a retry. The reset caused an IO > > exception to the waiting read thread which could check that a > > timeout had caused it. > > Ohh, the CAN controller must be reset? Though they would handle a > whole frame automatically. > I have no clue about this; surely it is very specific and complex. > The native interface resets it. In most cases, the only reason to reset it was so the native interface was freed up for a retry. If they had a interrupt() function, that may have been better. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. > This message may contain confidential and/or privileged information. If > you are not the addressee or authorized to receive this for the addressee, > you must not use, copy, disclose or take any action based on this message or > any information herein. If you have received this message in error, please > advise the sender immediately by reply e-mail and delete this message. Thank > you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/7df09a1e/attachment-0006.html From beat.arnet at gmail.com Mon May 18 13:27:07 2009 From: beat.arnet at gmail.com (Beat Arnet) Date: Mon, 18 May 2009 15:27:07 -0400 Subject: [Rxtx] Error 0x3e3 at termios.c(1301) Message-ID: All, I am experiencing a situation in which RXTX crashes consistently (both with 2.1 and 2.2). Steps to reproduce: - computer with JAVA program is sending bytes over RS-232 to embedded device, embedded device is off - embedded device powers up and transmit startup banner - JVM crashes: Error 0x3e3 at termios.c(1301) Any idea of what I should be looking for? Thanks! Beat # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6163696c, pid=808, tid=9648 # # Java VM: Java HotSpot(TM) Client VM (1.6.0-b105 mixed mode) # Problematic frame: # C 0x6163696c # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x0af7e400): JavaThread "Thread-4" [_thread_in_native, id=9648] siginfo: ExceptionCode=0xc0000005, reading address 0x6163696c Registers: EAX=0xffffffff, EBX=0x78652064, ECX=0x7c90f661, EDX=0x00000005 ESP=0x0c68f990, EBP=0x70706120, ESI=0x6f207469, EDI=0x6e612072 EIP=0x6163696c, EFLAGS=0x00010206 Top of Stack: (sp=0x0c68f990) 0x0c68f990: 6e6f6974 71657220 74736575 0a0a0d2e 0x0c68f9a0: 00000000 0c68f9d4 6d94556c 0daa3cb4 0x0c68f9b0: 74697277 74794265 3e0d2065 0a000a3e 0x0c68f9c0: 7c90cfea 7c80a059 000007d4 0af7e400 0x0c68f9d0: 6d909d8d 000007d4 00000002 6d945bf6 0x0c68f9e0: 0af7e400 00000001 00000000 0af8b024 0x0c68f9f0: 00000032 0af8b038 00000002 00000000 0x0c68fa00: 00000000 0af7e400 0af8b02c 06e85900 Instructions: (pc=0x6163696c) 0x6163695c: [error occurred during error reporting, step 100, id 0xc0000005] Stack: [0x0c640000,0x0c690000), sp=0x0c68f990, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C 0x6163696c [error occurred during error reporting, step 120, id 0xc0000005] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeByte(IZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write(I)V+86 j codeskin.serial.SerialPortRxtx2_1.write(I)V+29 j codeskin.c2oooprog.BootLoader2xxx$PingTask.run()V+87 v ~StubRoutines::call_stub -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/a692f306/attachment-0006.html From cowwoc at bbs.darktech.org Mon May 18 15:43:15 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Mon, 18 May 2009 17:43:15 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <4A119FC1.3090700@trustcommerce.com> Message-ID: <4A11D673.7080508@bbs.darktech.org> I'm in favor of using SerialPortChannel for timeouts and InputStream for non-blocking reads. This will allow us to follow the specification to the letter without any funky side-effects. In my view breaking the InputStream specification is a far greater sin than throwing InterruptedIOException from read(). Using SerialPortChannel and InputStream should allow us to please people in both camps without breaking the specification. Gili Bill Johnson wrote: > Hi Johnny, > > I think a SerialPortChannel could be a good example. It uses an > underlying Socket which uses an underlying implementation to support > open, timeouts, etc. As part of the implementation is where the current > RXTX could come in, provided there is a way to back out of a blocking > situation. > > +BillJ > > On Mon, May 18, 2009 at 1:49 PM, Johnny Luong > > > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Bill Johnson wrote: > | I can add this thought, I think the timeout is part of a protocol, > which > | should sit above RXTX. > > ... > > > Hi Bill, > > This is all conjecture and probably a lot of work in practice, so its > just a train of thought at this point (via NIO)... > > Supposer SerialPort were to implement a method that returned > "SerialPortChannel" which worked along similar lines as a SocketChannel. > ~ Then you could in practice, have a Selector object that did the > timeout > you described above (via a register method)... your read and write > methods could block or not block and it would be a lot easier to drive > multiple serial ports than what you have today. > > - -Johnny > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkoRn8EACgkQnQTBLXttTeXm0gCfaua0ej3Rt0fogRR68bbEFG0Z > BTwAn1s79U8ZU0yj6xcND8gyHzDmKKqq > =ThWj > -----END PGP SIGNATURE----- > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From bschlining at gmail.com Mon May 18 21:20:25 2009 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 18 May 2009 20:20:25 -0700 Subject: [Rxtx] Fwd: image capture In-Reply-To: References: Message-ID: forgot to cc the list ---------- Forwarded message ---------- From: Brian Schlining Date: Mon, May 18, 2009 at 20:19 Subject: Re: [Rxtx] image capture To: "Dr. Douglas Lyon" > Is anyone able to do image capture on a 64 bit mac, using > Java? Yes, I'm doing it from both video capture cards (Kona and Blackmagic) as well as from movie files. I'm only doing it on Java 5 (Mac) though. > QT4J is not loadable using Java 6 (AFAIK). Are you running this on a Mac or PC? Not that it matters I guess. QT4J is (unofficially) dead. It will be officially deprecated when Mac OS X 10.6 (Snow Leopard) is released, but for all practical purposes it's passed away. With each new release of QuickTime in the past year, I do the mad scramble to work around all the changes and bugs that are introduced. I'm working on once such 'fix' right now as a matter of fact. It's too bad too, QT4J was pretty darn powerful. Your best bet going forward is to rip out the QT4J code and replace it with a Mac/PC/Linux abstraction layer. On a Mac there you could try rococoa ( https://rococoa.dev.java.net) or just grab some QTKit samples off of Apples' developer site and write a JNI or JNA interface. On a PC, not sure what to tell you. I don't know what Apple's plans are with QT4J on a PC. They are pushing everyone away from QuickTime (C API) to QTKit (Cocoa/Objective-C). But on a PC ASFAIK there is no QTKit, so it's still QuickTime in the key of C. -- B ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/913800a4/attachment-0006.html From Kustaa.Nyholm at planmeca.com Tue May 19 00:26:27 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 19 May 2009 09:26:27 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A11D673.7080508@bbs.darktech.org> Message-ID: Oops, did it again, did not send this to the list, so we go: > > I'm in favor of using SerialPortChannel for timeouts and InputStream > for non-blocking reads. This will allow us to follow the specification > to the letter without any funky side-effects. > It was not clear to me what Gili is advocating here so I felt I needed to clarify this. > > In my view breaking the InputStream specification is a far greater sin > than throwing InterruptedIOException from read(). Throwing InterruptedIOException from InputStream.read() is just as big sin as it breaks the contract of InterruptedIOException , which says that the *thread* that was performing the IO was interrupted. Coneceptually I feel throwing an exception is a big sin in a situation which is not an error. A time out in a serial communication is almost always to be excepted since it is used to deal with real, live hardware outside the computer and very often it is a part of the higher level communication protocol, for example used to package or frame messages. Exceptions should be reserved for exceptional things not used for something that the programmer expects to happen normally. For one thing they incur an overhead. Granted, in a typical 9600 baud ie 1ms/char case the overhead is negligible, but it is there. On my 2.8 GHz Core 2 Duo try/throw/catch takes about 13 usec. In my view it is simply wrong to throw an exception for timeouts in a serial port. An even greater sin would be breaking existing code for design purity, at least in this case. > Using > SerialPortChannel and InputStream should allow us to please people in > both camps without breaking the specification. > So you are advocating adding a new class SerialPortChannel and a new method SerialPort.getSerialPortChannel() ? That would be acceptable in that it would not brake existing code but totally unnecessary in my view. I suspect most people turn to rxtx as a replacement for javacomm and are only interested in getting the job done. And the current API does this with very nicely. I think we all have better use for our time than to re-invent a serial port API. If the API bothers someone, I suggest they write a wrapper to implement the improvements and release it for interested users, if any. Would be kind of fun to see them struggle with all the API design issues and see what intellectual compromises they have to concede to. As a famous film ends in the sentence: "Nobody's perfect." cheers Kusti From Steffen.DETTMER at ingenico.com Tue May 19 02:12:14 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 19 May 2009 10:12:14 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A11D673.7080508@bbs.darktech.org> Message-ID: <20090519081214.GY17036@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Tue, May 19, 2009 at 09:26 +0300: > Coneceptually I feel throwing an exception is a big sin in a situation > which is not an error. Yes, I think the same. > In my view it is simply wrong to throw an exception for timeouts in > a serial port. Yes, I agree! > An even greater sin would be breaking existing code for design > purity, at least in this case. An even greater sin than that IMHO would be if the new stuff still isn't undoubtful powerful (which would IMHO need to include the possibility to select serial, TCP and other files simultaneously on systems that support it, e.g. for multi-serial-console applications or so). > So you are advocating adding a new class SerialPortChannel and > a new method SerialPort.getSerialPortChannel() ? SerialPortChannel would be a java.nio.channels.SelectableChannel or so? Or maybe a AbstractGatheringInterruptibleSelectableReadableWritableByteChannel. (the java name for `int fd' lol - SCNR). If changeing, I think an option could be to implement straightforward in native code offering its natural API (full timeout support, maybe as mandatory parameter, not dealing with Channel, Streams, source&sink, reactor&proactor patterns :-)). On top of that then both Channel and Stream and maybe something else for someone else. > That would be acceptable in that it would not brake existing code but > totally unnecessary in my view. I suspect most people turn to rxtx > as a replacement for javacomm and are only interested in getting the > job done. Yes, and most probably just have a few simultaneous connections. Others may need to have a dedicated, specialized and highly optimized JNI impl anyway (I guess). > If the API bothers someone, I suggest they write a wrapper to > implement the improvements and release it for interested users, > if any. Yes, actually that was what we did, but sometimes it was a bit cumbersome (because of InputStream and stuff). We implemented on top of that (instead of native interfaces or such) assuming that those interfaces won't change (but JNI interfaces probably are considered implementation details and thus probably will change). > Would be kind of fun to see them struggle with all the API > design issues and see what intellectual compromises they have > to concede to. Yeah, and then a nio successor comes and everone wanna go with it then :-) oki, Steffen ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Tue May 19 02:33:35 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 19 May 2009 10:33:35 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> Message-ID: <20090519083335.GZ17036@elberon.bln.de.ingenico.com> Hi! * Bill Johnson wrote on Mon, May 18, 2009 at 15:24 -0400: > * On Mon, May 18, 2009 at 1:54 PM, Steffen DETTMER wrote: > > * Bill Johnson wrote on Mon, May 18, 2009 at 13:08 -0400: > > > I can add this thought, I think the timeout is part of a > > > protocol, which should sit above RXTX. > > > > Probably actually on both levels timeouts can be helpful; if > > there is some PPP/TCP or other full duplex multiplexing > > protcol I think at least it is nice to be able to read with > > some reasonable timeout(s). > > I think timeout at the native level does not fit well with a > read() concept of timeout because it depends on the protocol > not really on the read(). What is special about `native level' to gain a special handling? I think all levels should support timeouts. Of course the read timeout an application invokes on a TCP stream has no direct relation to a PPP timeout and intercharacter timeouts on serial lines often depend on serial speed, CPU speed, required response timings, interrupt load etc, I think. So yes, I agree that protocols (often) define needed timeouts (to the lower layer) and the lower layer must offer support for timeouts. Is this what you mean with `depends on the protocol'? > > (this Bosch car protocol?) > > > > But if the protocol implementation knows the timeout value, > > wouldn't it be easier and suited better to have some way to apply > > it to the reads without needing multithreading? > > If you are waiting on a read and you are waiting on a timeout at the same > time, that is two logical threads. Ohh no, I disagree. I think, only if you have plenty of resources it is possible to waste a whole thread to watch a clock. When you have to read 100 connections of course you can use 100 threads, but better would be 1 thread with a select (or epoll or whatever), especially when assuming that the timeout is just a wait (thread sleep) time (when the OS is buffering the data anyway, which on Java running OSes probably is common). > Maybe you are looping check for one of two condition, character > or timeout, but I think its the same logically as waiting for a > character or a timeout exception. It is a special case where > you try to read except if it take too long, sound a little like > code? But isn't a maximum time a natural property of waiting? When you wait for someone for a meeting or so, you look to your watch from time to time and after half an hour or so you leave or continue your business. Select style IMHO is logically more event based than multi-threaded synchronous, but for applications or protocol implementations I found it comfortable when timeouts can be configured at any time. We even have two optional timeout parameters on our read function which eases implementing requirements like `receive both characters within 200 ms or reply with X'. > The CAN bus was Java on a TINI embedded system for a warehouse > system. It implemented a guaranteed delivery data path > patterned after the Datagram interface, I called it a Cangram > :-) The problem was how to cancel a read as part of a detected > protocol or controller error. The hardware was reset via the > native code driver which released resources so a restart was > successful. I may have garbaged a thread and started a new one > as part of it. cool :-) guess this was a very interesting project :) > I think it (reset, stop, interrupt, whatever) should be a > general requirement for any Java native interface code. Without > it, your application can lock up and there is no reasonable way > to regain control. alternatively, it could be required that any JNI function must return after some latest amount of time (i.e. specifying the maximum invocation time). I think, third-path-interruptions, maybe triggered from different threads, could quickly make code complicated because suddenly so many possible code paths can happen and they are hard to test (and cover). Personally, I think this is a major point against avoidable thread usage (even more if threads are not orthogonal) - hard to test, hard to ensure and prove it really is wrong always. Of course often enough it is needed anyway... oki, Steffen ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From michaeltandy at googlemail.com Tue May 19 08:33:09 2009 From: michaeltandy at googlemail.com (Michael Tandy) Date: Tue, 19 May 2009 15:33:09 +0100 Subject: [Rxtx] Rxtx native library loading Message-ID: <302aa0340905190733r4009e394v335b3ef47d84ffb5@mail.gmail.com> Attached is a patch which changes native library loading in Rxtx. Specifically, it makes two changes: 1. Looks in the directory RXTXcomm.jar is in for a native library, prior to searching java.library.path 2. Produces more informative error messages (in addition to the normal exceptions) if the native library cannot be found. The key benefits of this are: (a) to simplify setup; no need for administrator access to put things in shared/system directories, just unzip a file (containing my program as a .jar, RXTXcomm.jar, rxtxSerial.dll, librxtxSerial.so, and so on) and you're good to go; (b) If you've got multiple rxtx versions on your path (e.g. MATLAB puts its bin directory on your path, containing a copy of rxtxSerial.dll) you get the library file matching your jar file; (c) you don't need a big -Djava.library.path= every time you start your program; (d) if your native library file is missing, the error message is a bit more helpful (tells you where is being searched and for what); and (e) If the new code fails, it reverts to what the old code did, so it should be fully backwards-compatible. What do you think - is it worth including these changes in the main version of rxtx? Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: libraryloader.diff Type: text/x-diff Size: 10293 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090519/641c6573/attachment-0005.bin From bill7007 at gmail.com Tue May 19 12:37:32 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Tue, 19 May 2009 14:37:32 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090519083335.GZ17036@elberon.bln.de.ingenico.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> <20090519083335.GZ17036@elberon.bln.de.ingenico.com> Message-ID: On Tue, May 19, 2009 at 4:33 AM, Steffen DETTMER wrote: ... > > Is this what you mean with `depends on the protocol'? Native code is run time speed efficient, and that is important. I think I am saying, design wise, the function is read(). Timeout is a condition on read() only required by whatever comm protocol or comm logic you are using. I am thinking the whole purpose of SerialPort object is to represent a serial port so it should only contains methods and attributes of a serial port. A timeout is an event, part of the communication logic that is using that port. Wow, what a discussion. I had to go back and read it all to gather thoughts. I see multiple issues here. They coexist. 1) CommPort timeout implementation 2) Native blocking behavior and possible interruptions I think my protocol timeout thought was to state that the CommPort timeout may not be the best way implement a protocol timeout, but an alternative needs a blocking interrupt capability. Maybe that should be its own discussion. I do agree with the commandment, Thou shalt not modify the reference API. To focus back on Sun's CommPort interface, it does define a timeout that is optionally implemented and could be useful. I think a description of CommPort.getInputStream together with InputStream.read() leads to the implementation behavior: read() returns "the next byte of data, or -1 if the end of the stream is reached." So, end of stream must mean one of: 1) a timeout 2) "framing errors" (plural meaning parity and overrun too?) read(byte[]?b) returns "the total number of bytes read into the buffer, or -1 is there is no more data because the end of the stream has been reached." An end of stream here causes a return of the number read so far, or -1 if no data was yet read. How to determine cause of end of stream is a weakness of this API. Capturing a SerialPortEvent includes the framing error but not timeout. +BillJ From Steffen.DETTMER at ingenico.com Tue May 19 13:10:26 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 19 May 2009 21:10:26 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> <20090519083335.GZ17036@elberon.bln.de.ingenico.com> Message-ID: <20090519191025.GF17036@elberon.bln.de.ingenico.com> * Bill Johnson wrote on Tue, May 19, 2009 at 14:37 -0400: > methods and attributes of a serial port. A timeout is an event, part > of the communication logic that is using that port. (or the absence of data arrived events?) > read() returns "the next byte of data, or -1 if the end of the stream > is reached." > So, end of stream must mean one of: > 1) a timeout > 2) "framing errors" (plural meaning parity and overrun too?) I think neither timeout nor framing errors are end of stream (end of file) but only `remote DTR drop' is. I'm not sure (and always confuse) to which input line its maps and whether it is hi or lo active... I think, on linux, at least some versions, this worked well because when one side called close(fd) the other side read the EOF in exactly this moment. In general I think this is not reliable (different OSes surely handle it differently and it probably depends on several other things). With TCP sockets this can be expected to work (when one side shuts down its write channel, the other reads EOF after reading all data, which of course is returned first). Well, but probably some OS out there will be different just to annoy us :-) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From cowwoc at bbs.darktech.org Tue May 19 14:28:36 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 19 May 2009 16:28:36 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <4A131674.6000906@bbs.darktech.org> Guys, I am feeling very frustrated with this whole discussion. 1) There is no doubt that the current implementation breaks the InputStream API. A return value of -1 is already mapped to end-of-stream. For this reason, you *cannot* map the same value to a timeout. This is basic design-by-contract! 2) RXTX's implementation does not match javax.comm 100%. There are plenty of situations where the two implementations diverge. I am frustrated that people want to simultaneously freeze the APIs and fix issues that *cannot* be fixed purely in the implementation layer. 3) "Premature optimization is the root of all evil" and yet I see people complaining that exception handling costs 13 usec. Java places emphasizes correctness above performance. If you don't get that you shouldn't be coding in Java. More specific replies below... > Throwing InterruptedIOException from InputStream.read() is just as > big sin as it breaks the contract of InterruptedIOException , which > says that the *thread* that was performing the IO was interrupted. A thread getting interrupted is not the same as Thread.interrupt(). My interpretation is that interrupting the operation due to a timeout is a perfectly legal form of "thread interruption". Even with respect to Thread.interrupt(), you can't interrupt a thread, only the work it is executing. > Coneceptually I feel throwing an exception is a big sin in a situation > which is not an error. Exceptions refer to "exceptional circumstances" which is not the same as "errors". By that I mean that the "normally" the method returns 0-255, but exceptional cases such as timeouts are perfectly legal. > A time out in a serial communication is > almost always to be excepted since it is used to deal with real, live > hardware outside the computer I disagree. Some application-level protocols don't use timeouts at all. Why would your argument be true for serial connections but not sockets? > So you are advocating adding a new class SerialPortChannel and > a new method SerialPort.getSerialPortChannel() ? > > That would be acceptable in that it would not brake existing code but > totally unnecessary in my view. I suspect most people turn to rxtx > as a replacement for javacomm and are only interested in getting the > job done. And the current API does this with very nicely. I think > we all have better use for our time than to re-invent a serial port > API. The classic IO api is synchronous whereas NIO channels are asynchronous. Trying to retrofit timeouts on top of the old APIs will never be as clean as using NIO which is designed specifically for this purpose. Gili From tjarvi at qbang.org Tue May 19 17:19:15 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 May 2009 17:19:15 -0600 (MDT) Subject: [Rxtx] Rxtx native library loading In-Reply-To: <302aa0340905190733r4009e394v335b3ef47d84ffb5@mail.gmail.com> References: <302aa0340905190733r4009e394v335b3ef47d84ffb5@mail.gmail.com> Message-ID: On Tue, 19 May 2009, Michael Tandy wrote: > Attached is a patch which changes native library loading in Rxtx. > > Specifically, it makes two changes: > > 1. Looks in the directory RXTXcomm.jar is in for a native library, > prior to searching java.library.path > 2. Produces more informative error messages (in addition to the normal > exceptions) if the native library cannot be found. > > The key benefits of this are: > (a) to simplify setup; no need for administrator access to put things > in shared/system directories, just unzip a file (containing my program > as a .jar, RXTXcomm.jar, rxtxSerial.dll, librxtxSerial.so, and so on) > and you're good to go; > (b) If you've got multiple rxtx versions on your path (e.g. MATLAB > puts its bin directory on your path, containing a copy of > rxtxSerial.dll) you get the library file matching your jar file; > (c) you don't need a big -Djava.library.path= every time you start your program; > (d) if your native library file is missing, the error message is a bit > more helpful (tells you where is being searched and for what); > and (e) If the new code fails, it reverts to what the old code did, so > it should be fully backwards-compatible. > > What do you think - is it worth including these changes in the main > version of rxtx? > > Michael > Hi Michael, We will be putting a patch like yours in as soon as we release 2.2. The release was going to be mothers day but I got caught up :) I hope to do it next weekend. After that we will be looking at web installs which overlaps with your solution. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 19 17:44:25 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 May 2009 17:44:25 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A131674.6000906@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> Message-ID: On Tue, 19 May 2009, cowwoc wrote: >> A time out in a serial communication is >> almost always to be excepted since it is used to deal with real, live >> hardware outside the computer > > I disagree. Some application-level protocols don't use timeouts at all. > Why would your argument be true for serial connections but not sockets? > Hi Gili One fundamental difference between sockets, file io and RS232 communication is that sockets and file systems provide error handling. If a packet is lost, it is resent without the java API knowing about it. RS232 is actually an electrical signal standard. Serial communication exposes a UART without any meaningful error handling and cludgy error reporting. Given the above, ignoring timeouts is not really a valid rxtx level option. We could have a new option/method that allows you to get an InputStream or Channel that behaves as you wish. If we change the InputStream returned by getInputStream(), that would be change in the API (version 3.0) that forks our userbase. So I guess my question is whether or not you are trying to change the object returned by getInputStream or just looking for a means to get a different object you would like to define be returned. The later is far easier to accommodate. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 19 18:38:06 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 May 2009 18:38:06 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090519191025.GF17036@elberon.bln.de.ingenico.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> <20090519083335.GZ17036@elberon.bln.de.ingenico.com> <20090519191025.GF17036@elberon.bln.de.ingenico.com> Message-ID: On Tue, 19 May 2009, Steffen DETTMER wrote: > * Bill Johnson wrote on Tue, May 19, 2009 at 14:37 -0400: >> methods and attributes of a serial port. A timeout is an event, part >> of the communication logic that is using that port. > > (or the absence of data arrived events?) > >> read() returns "the next byte of data, or -1 if the end of the stream >> is reached." >> So, end of stream must mean one of: >> 1) a timeout >> 2) "framing errors" (plural meaning parity and overrun too?) > > I think neither timeout nor framing errors are end of stream (end > of file) but only `remote DTR drop' is. I'm not sure (and always > confuse) to which input line its maps and whether it is hi or lo > active... > There really is an end of input in termios that would match up fairly close in theory. The problem is it isnt really used as far as I know. termois.c_cc[VEOF] - the end of input character. I assume it is control-d. If you have a terminal open, try typing it into the shell prompt :) We even have some access to it in rxtx as extensions to commapi: private native byte nativeGetEndOfInputChar( ) throws UnsupportedCommOperationException; private native boolean nativeSetEndOfInputChar( byte b ) throws UnsupportedCommOperationException; GPIB has an entire wire dedicated to "EOI." -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue May 19 19:07:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 19 May 2009 21:07:34 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> Message-ID: <4A1357D6.9090705@bbs.darktech.org> Hi Trent, > RS232 is actually an electrical signal standard. Serial communication > exposes a UART without any meaningful error handling and cludgy error > reporting. > > Given the above, ignoring timeouts is not really a valid rxtx level > option. We could have a new option/method that allows you to get an > InputStream or Channel that behaves as you wish. Why? You could always use available() alongside blocking reads. > If we change the InputStream returned by getInputStream(), that would be > change in the API (version 3.0) that forks our userbase. > > So I guess my question is whether or not you are trying to change the > object returned by getInputStream or just looking for a means to get a > different object you would like to define be returned. > > The later is far easier to accommodate. I expect users to use getInputStream() for blocking reads and getInputChannel() for non-blocking reads. I understand your objections and normally I'd agree to wait for version 3.0 but RXTX's violation of the specification is a critical flaw in my opinion. Don't take my word for it... Take a look at this post I just ran across: http://stackoverflow.com/questions/611760/java-inputstream-read-blocking ------ quote ------- A read of -1 isn't doesn't mean, "there's no data present on this attempt," it means, "the stream is closed and there will never be any data so stop asking." If the end of the stream has not been reached, a read() call will block, just as the documentation specifies. [...] I've only used javax.comm for serial port I/O, and it implements InputStream as intended. It's possible that the rxtx implementation violates the contract of InputStream.read(), but if so, that's a very bad thing. Any code that was written to work with InputStream in general relies on the fact that -1 means EOF. Passing a broken java.io.InputStream to such code will cause problems. If rxtx supports non-blocking I/O, they should have created their own interface for reading, not extended InputStream. ------ quote ------- We learn two things from this post: 1) javax.comm respects the InputStream contract. It does not return -1 on timeouts. Seeing how you've written that any deviation from the javax.comm implementation is a bug I would suggest that this should be fixed immediately. 2) Violating the superclass specification can introduce an untold number of bugs. For example, I spent hours trying to figure out why BufferedReader.readLine() was returning null while the connection was still open. Gili From tjarvi at qbang.org Tue May 19 19:23:13 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 May 2009 19:23:13 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A1357D6.9090705@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> Message-ID: On Tue, 19 May 2009, cowwoc wrote: > > 1) javax.comm respects the InputStream contract. It does not return -1 on > timeouts. Seeing how you've written that any deviation from the javax.comm > implementation is a bug I would suggest that this should be fixed > immediately. > Hi Gili What is the observed behavior of javax.comm on timeout? Are you sure it didn't just disable timeouts by default? -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue May 19 19:37:24 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 19 May 2009 21:37:24 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> Message-ID: <4A135ED4.3090608@bbs.darktech.org> Trent Jarvi wrote: >> 1) javax.comm respects the InputStream contract. It does not return -1 >> on timeouts. Seeing how you've written that any deviation from the >> javax.comm implementation is a bug I would suggest that this should be >> fixed immediately. > What is the observed behavior of javax.comm on timeout? Are you sure it > didn't just disable timeouts by default? I'm not sure. Unfortunately, I've never gotten javax.comm to work under Windows and I don't have access to any other platform at this time. I assume that you've used javax.comm before, so I encourage you to try it on your end. Whatever they did, I really don't think that Sun would have violated the InputStream specification by returning -1 on timeout. As the BufferedReader.readLine() example shows, doing so triggers a lot of bugs. Gili From tjarvi at qbang.org Tue May 19 20:01:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 May 2009 20:01:53 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A135ED4.3090608@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> <4A135ED4.3090608@bbs.darktech.org> Message-ID: On Tue, 19 May 2009, cowwoc wrote: > Trent Jarvi wrote: >>> 1) javax.comm respects the InputStream contract. It does not return -1 on >>> timeouts. Seeing how you've written that any deviation from the javax.comm >>> implementation is a bug I would suggest that this should be fixed >>> immediately. > >> What is the observed behavior of javax.comm on timeout? Are you sure it >> didn't just disable timeouts by default? > > I'm not sure. Unfortunately, I've never gotten javax.comm to work > under Windows and I don't have access to any other platform at this time. I > assume that you've used javax.comm before, so I encourage you to try it on > your end. Whatever they did, I really don't think that Sun would have > violated the InputStream specification by returning -1 on timeout. As the > BufferedReader.readLine() example shows, doing so triggers a lot of bugs. > I've actually never used the Sun implementation. RXTX and CommAPI have very different origins that overlap with Kevin Hester's "JCL" patch to bring them together. The rest has been done from the docs. Default settings have always been a source of confusion which is why I ask. Disabled timeouts/thresholds would behave like you expect. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue May 19 20:30:22 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 19 May 2009 22:30:22 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> <4A135ED4.3090608@bbs.darktech.org> Message-ID: <4A136B3E.7010704@bbs.darktech.org> Trent Jarvi wrote: > What is the observed behavior of javax.comm on timeout? Are you sure > it didn't just disable timeouts by default? Can someone who has used javax.comm please investigate this and let us know? Thanks, Gili From Steffen.DETTMER at ingenico.com Wed May 20 02:30:08 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 20 May 2009 10:30:08 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A131674.6000906@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> Message-ID: <20090520083008.GH17036@elberon.bln.de.ingenico.com> * cowwoc wrote on Tue, May 19, 2009 at 16:28 -0400: > Guys, I am feeling very frustrated with this whole discussion. (Me too, but probably for different reason :-)) > 1) There is no doubt that the current implementation breaks the > InputStream API. (which must happen, because InputStream as defined is less usable) > A return value of -1 is already mapped to end-of-stream. For > this reason, you *cannot* map the same value to a timeout. This > is basic design-by-contract! Currently (actually we are still using RXTX-2.1-7 which surely isn't the latest version :)), in case of timeout read(byte[]) returns 0. We have a wrapper implementation (which because of some rxtx timeout precision issues) might be a few lines more than needed but provides timeout precision typical better than 100ms (for us, this is sufficient). I wrote about it here some years ago. So it's possible to work with rxtx even with InputStream. Not very comfortable thanks for InputStream, but it works. Java developers expect InputStream (with its limitations). I was told this several times. May the java and javax APIs suck or not, but it is what most java developers are used to use, expect and what we live with in so many other areas, too. > 2) RXTX's implementation does not match javax.comm 100%. There > are plenty of situations where the two implementations diverge. > I am frustrated that people want to simultaneously freeze the > APIs and fix issues that *cannot* be fixed purely in the > implementation layer. As already written, I think a `real complete exhaustive fix' isn't possible or desired here for various reasons. The current way works well and complies to java stuff as much as possible (the differences are enforced logically and the InputStream specification IMHO is simply wrong). Now why change, requiring people to redevelop their applications or wrappers? Why not alternatively publish one of those wrappers (yours? :-)) under a public license and/or add it to rxtx allowing people that want exceptions allowing them to use configurable exceptions (for example)? > 3) "Premature optimization is the root of all evil" and yet I > see people complaining that exception handling costs 13 usec. > Java places emphasizes correctness above performance. If you > don't get that you shouldn't be coding in Java. In general, also `oversimplification is a root of evil' and IMHO nice examples can be found in Java APIs, but this is the way `everyone' goes. Raping exceptions as return codes IMHO is not a performance problem but a design problem (in a non-RAII-aware language which is not allowing ensured resource cleanups by guaranteed destructors this is a real big problem, IMHO). I don't understand the discussion. We have a read returning number of bytes read. We have situations where no byte is read. Now the API doesn't tell that in this case zero should be returned, but I think this is so damn obvious, isn't it?? > > A time out in a serial communication is almost always to be > > excepted since it is used to deal with real, live hardware > > outside the computer > > I disagree. Some application-level protocols don't use timeouts > at all. Why would your argument be true for serial connections > but not sockets? In general, everything has (or should have) timeouts /or/ be under control of something. Technically, the latter may require use `timeouts in a loop' (some polling). TCP has timeouts, for instance retransmission timeouts. Situations were no timeouts are defined in TCP (was it e.g. FIN_WAIT?) in the past lead to issues. On real OSes there are also UDP sockets, UNIX Domain Sockets and whatever else - and all of them and serial ports can accessed via one and the same API and select'd at the same time: timeout supported is simply built-in. For complex protcols, like TCP, all the heaps of defined timeouts might not be as visible as for serial case, where typical applications handle details themself, but they exist. > The classic IO api is synchronous whereas NIO channels are > asynchronous. Trying to retrofit timeouts on top of the old > APIs will never be as clean as using NIO which is designed > specifically for this purpose. I think classic is BSD socket API, which IMHO looks like a natural evolution of classic unix APIs. Works also for serial and everything (at least on unix and cygwin). I think Java people didn't saw the big picture and tried to simplify but oversimplified, assuming, InputStream could be used for all types of communication. Actually, it even can, but not alone (usually, you additionally need OutputStream and some ioctl). Now of course it was nice and sexy to critise the non-type-safe ioctl and select and to drop it - but this of course is no solution. Just ignoring the difficulties rarely helps. NIO is a bit more BSD socket API style, a step into the direction where everything comes from. Next version might take another step and reach the goal. Who knows. As far as I know none of the issues that lead to NIO (mostly performance and scalability) apply to rxtx. The only thing that seems to appy is that some buggy Javadoc tells InputStream would be blocking, available has no timeout, write timeouts are also not supported - and read(byte[]) never returns 0. Which quickly, easily and straightforward `fixes' the issues. That is what rxtx did. Isn't this fine? oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From m.j.tandy at warwick.ac.uk Wed May 20 03:01:51 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 20 May 2009 10:01:51 +0100 Subject: [Rxtx] InputStream timeouts In-Reply-To: <302aa0340905200201r912d9d0m6c9e1e41e049f1df@mail.gmail.com> References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> <302aa0340905200201r912d9d0m6c9e1e41e049f1df@mail.gmail.com> Message-ID: <302aa0340905200201t13a31a4bq30f60042c50fde63@mail.gmail.com> > 2) Violating the superclass specification can introduce an untold number > of bugs. For example, I spent hours trying to figure out why > BufferedReader.readLine() was returning null while the connection was > still open. We're discussing what the read() method does on timeout - but isn't the failure of BufferedReader.readLine caused by read(byte[] b, int off, int len) returning '0 bytes read' - not caused by what the read() method does on timeout? I mean, when I run the code below (Java 1.6.0_13-b03 / Sun JDK 6) the output is: Attempting to read a line... program called inputstream's read(byte[] b, int off, int len) java.io.IOException: Underlying input stream returned zero bytes ? ? ? ?at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) ? ? ? ?at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) ? ? ? ?at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) ? ? ? ?at java.io.InputStreamReader.read(InputStreamReader.java:167) ? ? ? ?at java.io.BufferedReader.fill(BufferedReader.java:136) ? ? ? ?at java.io.BufferedReader.readLine(BufferedReader.java:299) ? ? ? ?at java.io.BufferedReader.readLine(BufferedReader.java:362) ? ? ? ?at inputstreamtest.Main.main(Main.java:14) And if I look at the source code for StreamDecoder.java [1] I see the following lines: ?283 ? ? ? ? ? ? ? int n = in.read(bb.array(), bb.arrayOffset() + pos, rem); ?284 ? ? ? ? ? ? ? if (n < 0) ?285 ? ? ? ? ? ? ? ? ? return n; ?286 ? ? ? ? ? ? ? if (n == 0) ?287 ? ? ? ? ? ? ? ? ? throw new IOException("Underlying input stream returned zero bytes"); Which kind of makes sense, because the javadoc for read(byte[] b, int off, int len) [2] does explicitly say that "If len is zero, then no bytes are read and 0 is returned; otherwise, there is an attempt to read at least one byte. If no byte is available because the stream is at end of file, the value -1 is returned; otherwise, at least one byte is read and stored into b." Is this the problem that you encountered? Michael [1] http://www.docjar.com/html/api/sun/nio/cs/StreamDecoder.java.html [2] http://java.sun.com/javase/6/docs/api/java/io/InputStream.html#read(byte[],%20int,%20int) // CODE BEGINS HERE package inputstreamtest; import java.io.BufferedReader; import java.io.IOException; import java.io.InputStream; import java.io.InputStreamReader; public class Main { ? ?public static void main(String[] args) { ? ? ? ?BufferedReader in = new BufferedReader(new InputStreamReader(new FakeInputStream())); ? ? ? ?System.out.println("Attempting to read a line..."); ? ? ? ?try { ? ? ? ? ? ?in.readLine(); ? ? ? ?} catch (IOException e) { ? ? ? ? ? ?e.printStackTrace(); ? ? ? ?} ? ?} ? ?private static class FakeInputStream extends InputStream { ? ? ? ?@Override ? ? ? ?public int read(byte[] b, int off, int len) { ? ? ? ? ? ?System.out.println("program called inputstream's read(byte[] b, int off, int len)"); ? ? ? ? ? ?return 0; ? ? ? ?} ? ? ? ?@Override ? ? ? ?public int read() throws IOException { ? ? ? ? ? ?System.out.println("program called inputstream's read()"); ? ? ? ? ? ?return -1; ? ? ? ?} ? ?} } From Steffen.DETTMER at ingenico.com Wed May 20 03:16:20 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 20 May 2009 11:16:20 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> <20090519083335.GZ17036@elberon.bln.de.ingenico.com> <20090519191025.GF17036@elberon.bln.de.ingenico.com> Message-ID: <20090520091620.GI17036@elberon.bln.de.ingenico.com> * Trent Jarvi wrote on Tue, May 19, 2009 at 18:38 -0600: > >I think neither timeout nor framing errors are end of stream (end > >of file) but only `remote DTR drop' is. I'm not sure (and always > >confuse) to which input line its maps and whether it is hi or lo > >active... > > There really is an end of input in termios that would match up > fairly close in theory. The problem is it isnt really used as > far as I know. > > termois.c_cc[VEOF] - the end of input character. I assume it > is control-d. If you have a terminal open, try typing it into > the shell prompt :) Ahh yes, this way it was! (what means `logged out' and why my modem has no carrier?! :)) With a null modem cable and a C++ implementation I tried it and found that you are right, it is working with ^D (but not with DTR as I claimed), thanks for the correction. In `stty raw' ^D is 0x04 but after `stty sane' ^D works as end of input character, as you said. select(2) tells ready for read and read(2) return 0 bytes, which means EOF :-) (Well, in strict pure theory I think this could be considered a property of the terminal line discipline canonical mode, which IMHO could be considered a protocol property) BTW, is someone using this EOF in general? Our C++ implementation supports both it seems it (EOF detection) was never used. I guess it depends on the domain someone is working in? I could imagine that some micro controller control interfaces use that? oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed May 20 03:32:00 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 20 May 2009 11:32:00 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> <20090519083335.GZ17036@elberon.bln.de.ingenico.com> <20090519191025.GF17036@elberon.bln.de.ingenico.com> Message-ID: <20090520093200.GK17036@elberon.bln.de.ingenico.com> ps. our java implementation using RXTX-2.1-7 (surely very old) does not detect the ^D in `stty sane' mode. also, just BTW, about the IOException interruption discussion. When I aborted the java command line test program by ^C, I got IOException: java.io.IOException: Interrupted system call in readArray which IMHO shows that Kusti is right. The code not detecting EOF is similar to: port_.enableReceiveTimeout(intTimeout); bytesRead = port_.getInputStream().read( buffer, totalBytesRead, bytesRequested ); switch (bytesRead) { case -1: readClosedByPeer_ = true; break; case 0: // log interchar timeout if (totalBytesRead > 0) { rs232Logger_.finest( "Intercharacter timeout (" + getByteReadTimeout() + " ms) while reading, might be Ok. Returning " + totalBytesRead + " bytes read so far" ); } if (!ENABLE_RECEIVE_TIMEOUT_PRECISION_LOGGING) { break; } So actually I don't know if readClosedByPeer ever worked (we don't use it anyway I think). oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Wed May 20 03:57:30 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 12:57:30 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <302aa0340905200201t13a31a4bq30f60042c50fde63@mail.gmail.com> Message-ID: > From: Michael Tandy > And if I look at the source code for StreamDecoder.java [1] I see the > following lines: > ?283 ? ? ? ? ? ? ? int n = in.read(bb.array(), bb.arrayOffset() + pos, rem); > ?284 ? ? ? ? ? ? ? if (n < 0) > ?285 ? ? ? ? ? ? ? ? ? return n; > ?286 ? ? ? ? ? ? ? if (n == 0) > ?287 ? ? ? ? ? ? ? ? ? throw new IOException("Underlying input stream > returned zero bytes"); > > Which kind of makes sense, because the javadoc for read(byte[] b, int > off, int len) [2] does explicitly say that "If len is zero, then no > bytes are read and 0 is returned; otherwise, there is an attempt to > read at least one byte. If no byte is available because the stream is > at end of file, the value -1 is returned; otherwise, at least one byte > is read and stored into b." Not realy relevant for the discussion but out of curiosity I had peek at the code you quoted and just a few lines above we see: 278 int lim = bb.limit(); 279 int pos = bb.position(); 280 assert (pos <= lim); 281 int rem = (pos <= lim ? lim - pos : 0); 282 assert rem > 0; If asserts are disabled (the default IIRC) then 'rem' could be 0 in which case throwing exception on line 287 is not correct in that it is legal for read(byte[]) to return under that circumstance. Of course it maybe that the design of StreamDecoder otherwise guarantees that lim > pos but this just shows how difficult it is to be logically consistent all the time. Further browsing the StreamDecoder and CharsetDecorder classes it seems, at least superficially, that nothing has been gained by checking and throwing an exception, the rest of code would have worked correctly even if the the read on line 283 would return 0. All code that I've ever written have handled read(byte[]) returning 0 correctly (touch wood!) taking it on it's stride. Why not, you need to prepare for read to return less than what you asked so it naturally falls to handle the case of 0 also. From Kustaa.Nyholm at planmeca.com Wed May 20 04:06:12 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 13:06:12 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090520083008.GH17036@elberon.bln.de.ingenico.com> Message-ID: > From: Steffen DETTMER > >> 1) There is no doubt that the current implementation breaks the >> InputStream API. > (which must happen, because InputStream as defined is less usable) > Exactly. > Now why change, requiring people to redevelop their applications > or wrappers? Why not alternatively publish one of those wrappers > (yours? :-)) under a public license and/or add it to rxtx > allowing people that want exceptions allowing them to use > configurable exceptions (for example)? > Hear,hear, agree whole heartedly! > > I don't understand the discussion. We have a read returning > number of bytes read. We have situations where no byte is read. > Now the API doesn't tell that in this case zero should be > returned, but I think this is so damn obvious, isn't it?? To me it is soooooo obvious. > > The only thing that seems to appy is that some buggy Javadoc > tells InputStream would be blocking, available has no timeout, > write timeouts are also not supported - and read(byte[]) never > returns 0. Which quickly, easily and straightforward `fixes' the > issues. That is what rxtx did. Isn't this fine? It is fine. It ain't broken, don't fix it. This is mainly a documentation issue. When the map and scenery disagree trust the scenery. Thanks Steffen for summing it up so nicely! cheers Kusti From cowwoc at bbs.darktech.org Wed May 20 04:39:31 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 06:39:31 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090520083008.GH17036@elberon.bln.de.ingenico.com> References: <4A131674.6000906@bbs.darktech.org> <20090520083008.GH17036@elberon.bln.de.ingenico.com> Message-ID: <4A13DDE3.8070703@bbs.darktech.org> Steffen DETTMER wrote: > * cowwoc wrote on Tue, May 19, 2009 at 16:28 -0400: >> Guys, I am feeling very frustrated with this whole discussion. > > (Me too, but probably for different reason :-)) > >> 1) There is no doubt that the current implementation breaks the >> InputStream API. > > (which must happen, because InputStream as defined is less usable) Not true. Either we follow the InputSteam specification or we define our own interface. Breaking the specification in this way will trigger unpredictable bugs. > Currently (actually we are still using RXTX-2.1-7 which surely > isn't the latest version :)), in case of timeout read(byte[]) > returns 0. > > I don't understand the discussion. We have a read returning > number of bytes read. We have situations where no byte is read. > Now the API doesn't tell that in this case zero should be > returned, but I think this is so damn obvious, isn't it?? Actually, the Javadoc for read(byte[]) says that at least one byte must be read: "If the length of b is zero, then no bytes are read and 0 is returned; otherwise, there is an attempt to read at least one byte. If no byte is available because the stream is at the end of the file, the value -1 is returned; otherwise, at least one byte is read and stored into b." > In general, everything has (or should have) timeouts /or/ be > under control of something. Technically, the latter may > require use `timeouts in a loop' (some polling). TCP has > timeouts, for instance retransmission timeouts. Situations were > no timeouts are defined in TCP (was it e.g. FIN_WAIT?) in the > past lead to issues. On real OSes there are also UDP sockets, > UNIX Domain Sockets and whatever else - and all of them and > serial ports can accessed via one and the same API and select'd > at the same time: timeout supported is simply built-in. > For complex protcols, like TCP, all the heaps of defined timeouts > might not be as visible as for serial case, where typical > applications handle details themself, but they exist. Fair enough, but "timeouts in a loop" -- using available() -- don't break the InputStream specification. > NIO is a bit more BSD socket API style, a step into the direction > where everything comes from. Next version might take another step > and reach the goal. Who knows. As far as I know none of the > issues that lead to NIO (mostly performance and scalability) > apply to rxtx. NIO allows you to select() on a channel with a timeout, which is the point of contention. > The only thing that seems to appy is that some buggy Javadoc > tells InputStream would be blocking, available has no timeout, > write timeouts are also not supported - and read(byte[]) never > returns 0. Which quickly, easily and straightforward `fixes' the > issues. That is what rxtx did. Isn't this fine? I'm not sure I understand. I get that you dislike that InputStream doesn't provide facilities for non-blocking reads but that is just life. You're supposed to either create your own interface or use NIO for that. In my view, breaking the superclass contract is always worse than inconveniencing yourself. Gili From cowwoc at bbs.darktech.org Wed May 20 04:41:14 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 06:41:14 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <302aa0340905200201t13a31a4bq30f60042c50fde63@mail.gmail.com> References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> <302aa0340905200201r912d9d0m6c9e1e41e049f1df@mail.gmail.com> <302aa0340905200201t13a31a4bq30f60042c50fde63@mail.gmail.com> Message-ID: <4A13DE4A.70704@bbs.darktech.org> Yes. Gili Michael Tandy wrote: >> 2) Violating the superclass specification can introduce an untold number >> of bugs. For example, I spent hours trying to figure out why >> BufferedReader.readLine() was returning null while the connection was >> still open. > > We're discussing what the read() method does on timeout - but isn't > the failure of BufferedReader.readLine caused by read(byte[] b, int > off, int len) returning '0 bytes read' - not caused by what the read() > method does on timeout? > > I mean, when I run the code below (Java 1.6.0_13-b03 / Sun JDK 6) the output is: > > Attempting to read a line... > program called inputstream's read(byte[] b, int off, int len) > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > at inputstreamtest.Main.main(Main.java:14) > > And if I look at the source code for StreamDecoder.java [1] I see the > following lines: > 283 int n = in.read(bb.array(), bb.arrayOffset() + pos, rem); > 284 if (n < 0) > 285 return n; > 286 if (n == 0) > 287 throw new IOException("Underlying input stream > returned zero bytes"); > > Which kind of makes sense, because the javadoc for read(byte[] b, int > off, int len) [2] does explicitly say that "If len is zero, then no > bytes are read and 0 is returned; otherwise, there is an attempt to > read at least one byte. If no byte is available because the stream is > at end of file, the value -1 is returned; otherwise, at least one byte > is read and stored into b." > > Is this the problem that you encountered? > > Michael > > [1] http://www.docjar.com/html/api/sun/nio/cs/StreamDecoder.java.html > [2] http://java.sun.com/javase/6/docs/api/java/io/InputStream.html#read(byte[],%20int,%20int) > > > // CODE BEGINS HERE > package inputstreamtest; > > import java.io.BufferedReader; > import java.io.IOException; > import java.io.InputStream; > import java.io.InputStreamReader; > > public class Main { > > public static void main(String[] args) { > BufferedReader in = new BufferedReader(new > InputStreamReader(new FakeInputStream())); > System.out.println("Attempting to read a line..."); > try { > in.readLine(); > } catch (IOException e) { > e.printStackTrace(); > } > } > > private static class FakeInputStream extends InputStream { > @Override > public int read(byte[] b, int off, int len) { > System.out.println("program called inputstream's > read(byte[] b, int off, int len)"); > return 0; > } > > @Override > public int read() throws IOException { > System.out.println("program called inputstream's read()"); > return -1; > } > } > > } > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From cowwoc at bbs.darktech.org Wed May 20 04:45:25 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 06:45:25 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <4A13DF45.7030305@bbs.darktech.org> Kustaa Nyholm wrote: > It is fine. It ain't broken, don't fix it. This is mainly > a documentation issue. When the map and scenery disagree trust > the scenery. This isn't "documentation". It's a specification. The core Java APIs implement it perfectly and expect it to be followed 100% of the time. It is impossible to change it this late in the game. Gili From Kustaa.Nyholm at planmeca.com Wed May 20 06:03:15 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 15:03:15 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A131674.6000906@bbs.darktech.org> Message-ID: > > Guys, I am feeling very frustrated with this whole discussion. I feel your pain as I'm frustrated, not by the discussion which has been conducted in a gentlemanly maner and has entertained me quite a lot, but by people trying to fix what ain't broken. > > 1) There is no doubt that the current implementation breaks the > InputStream API. Well, this is like saying my car is broken because a mouse ate the registration paper (honestly, that happened last winter). There is only a very minor discrepancy between what a few document sentences says and what *useful and practical* functionality the current rxtx/javacomm provides. > A return value of -1 is already mapped to > end-of-stream. For this reason, you *cannot* map the same value to a > timeout. This is basic design-by-contract! I thought we already agreed (talking about read(byte[])) 0 should be returned and AFAIK *is* returned. And this matches the javadoc for CommPort.getInputStream() which says that it return a kind of InputStream where read operations blocks until a timeout occurs OR until any data is available. So it can return even when no data is available. And in that case 0 seems like an appropriate return value. It bends the rules of InputStream a bit, but this is by design, not error. Now, if read() returns -1 in case of timeout this is a dilemma as it does allow differentiation between EOF (whatever it means for serial stream) and timeout. However the 'golden standard', the stream object that javacomm.SerialPort.getInputStream().read(), returns in case of timeout is -1, at least on Windows (just tested it). And we should not brake this compatibility. > > 2) RXTX's implementation does not match javax.comm 100%. > So? Why make it match even less? Most people want compatibility and usability, not semantic / logical correctness at least as far as something as small as serial port API is concerned. Go write your own wrapper if it bother you. > There are > plenty of situations where the two implementations diverge. If there are, please let us know, this is very useful information for any rxtx user so that they can avoid these pitfalls. > I am > frustrated that people want to simultaneously freeze the APIs and fix > issues that *cannot* be fixed purely in the implementation layer. What issues you mean? Off hand I don't recall people asking for fixes that would match your description of "that *cannot* be fixed purely in the implementation layer". Personally, all I've ever wanted from javacomm and rxtx was to be able to access the serial port from Java in platform neutral fashion that allows my code to run on the three major platforms Mac OS X, Linux and Windows. And rxtx delivers just that. > > 3) "Premature optimization is the root of all evil" and yet I see people > complaining that exception handling costs 13 usec. I'm sure you understood that 13 usec was not the point. The point is that exception handling concept has been designed to handle exceptional case which are rare and thus performance of the code when an exception is thrown can be slow. The penalty is not specified but includes creating a new object or several (stack trace) and frequently warned about. Like I said, and I'm sure you understood, at 9600 baud this penalty is not an issue, but in a slower machine (mine was, as stated 2.8 GHz/4GB/1066MHz Core 2 Duo), or different JVM, or JIT not happening (BTW exception handling disturbs JIT) it could be a decade slower. So make it 100 usec and raise baud rate to 1 MBps now merely throwing the exception takes ten times longer than a one character timeout. Many protocols I have programmed have used pauses of less than that to frame messages. IMO it would be serious mistake to use exceptions to handle timeouts. Ever wondered why EOF is signaled with -1 and not an exception... > Java places > emphasizes correctness above performance. If you don't get that you > shouldn't be coding in Java. This is not what I would call parliamentary language. I won't reply. > > More specific replies below... > >> Throwing InterruptedIOException from InputStream.read() is just as >> big sin as it breaks the contract of InterruptedIOException , which >> says that the *thread* that was performing the IO was interrupted. > > A thread getting interrupted is not the same as Thread.interrupt(). Oh yeah? Really? In the context it was used I beg to differ. > My interpretation is that interrupting the operation due to a timeout is a > perfectly legal form of "thread interruption". Even with respect to > Thread.interrupt(), you can't interrupt a thread, only the work it is > executing. > >> Coneceptually I feel throwing an exception is a big sin in a situation >> which is not an error. > > Exceptions refer to "exceptional circumstances" which is not the same > as "errors". By that I mean that the "normally" the method returns > 0-255, but exceptional cases such as timeouts are perfectly legal. But timeout with SerialPort usually is not an exceptional case. But I guess you are fixed to your idea that it is. The important thing however is that it is not for me or you to decide and thus it is not for the API to dictate this. > >> A time out in a serial communication is >> almost always to be excepted since it is used to deal with real, live >> hardware outside the computer > > I disagree. Some application-level protocols don't use timeouts at > all. > Why would your argument be true for serial connections but not sockets? What Sockets and application level protocols have got to do with reading a SerialPort/RS232 port and it's timeouts? > >> So you are advocating adding a new class SerialPortChannel and >> a new method SerialPort.getSerialPortChannel() ? >> >> That would be acceptable in that it would not brake existing code but >> totally unnecessary in my view. I suspect most people turn to rxtx >> as a replacement for javacomm and are only interested in getting the >> job done. And the current API does this with very nicely. I think >> we all have better use for our time than to re-invent a serial port >> API. > > The classic IO api is synchronous whereas NIO channels are > asynchronous. Trying to retrofit timeouts on top of the old APIs will > never be as clean as using NIO which is designed specifically for this > purpose. > You maybe right, but the cure is worse than the disease and the first rule of a good doctor is to "do no harm". What you are concerned about is some semantic details what most of us are concerned with is getting the job done. Here are some more thoughts on using exceptions in case you can be bothered. Quoting from Sun's exception handling tutorial: http://java.sun.com/docs/books/tutorial/essential/exceptions/throwing.html "An Exception indicates that a problem occurred" Now, a timeout, to me, is not a problem, but very often an essential part of the communication protocol. Of course for some in some situations it maybe a problem, but that is not for the (communication) API designer to decide or dictate. To me this spells that timeouts should not throw an exception. Also from the same document: "Here's the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception." Following this guideline would dictate that timeout exception should be a checked exception (because surely almost universally the programmer who enables timeouts (disable by default, remember) can and will handle the timeouts in some reasonable way. *Adding a checked exception toInputStream.reads is not possible.* Again this speaks against throwing an exception in case of timeouts. More in the same vein: http://developer.apple.com/documentation/Performance/Conceptual/CodeSpeed/Ar ticles/TuningJavaCode.html#//apple_ref/doc/uid/TP40002329-DontLinkElementID_ 4 "Exception handling in Java is very slow. ... use exceptions only for truly exceptional cases. Do not use exceptions to indicate simple errors from which your code could otherwise recover. Instead, use them only to indicate abnormal conditions that your code does not know how to handle." cheers Kusti From Kustaa.Nyholm at planmeca.com Wed May 20 06:20:34 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 15:20:34 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A13DDE3.8070703@bbs.darktech.org> Message-ID: > > Not true. Either we follow the InputSteam specification or we define > our own interface. Breaking the specification in this way will trigger > unpredictable bugs. Well bugs are by their very nature unpredictable, what? But seriously who are you to dictate "high road or low road"? Who says we (whoever that 'we' are) must either follow 100% or define our own? If 'we' want to take a middle road we surely can. And I'm all for it. Pursuing 100% clean designs is a fruitless goal and I've got better things to do than keep updating my code base to track an ever changing API in pursuit of an unattainable internal and external purity and correctness. > > Fair enough, but "timeouts in a loop" -- using available() -- don't > break the InputStream specification. So why not use it? If you do not touch the enableTimeout() and enableThreshold() methods the SerialPort.InputStream fulfills the contract to the letter. And if you touch them, it fulfills the commitment that creators of the original API made. > You're supposed to either create your own interface or use NIO for that. > In my view, breaking the superclass contract is always worse than > inconveniencing yourself. Why don't you provide a proof of concept framework of classes and interfaces that are internally and externally consistent for us to scrutinize? I bet it will contain one or two compromises and bending of the rules or be totally out of tune what people need or want to use. cheers Kusti From Steffen.DETTMER at ingenico.com Wed May 20 07:23:40 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 20 May 2009 15:23:40 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A13DDE3.8070703@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> <20090520083008.GH17036@elberon.bln.de.ingenico.com> <4A13DDE3.8070703@bbs.darktech.org> Message-ID: <20090520132339.GB27170@elberon.bln.de.ingenico.com> * cowwoc wrote on Wed, May 20, 2009 at 06:39 -0400: > >>1) There is no doubt that the current implementation breaks the > >>InputStream API. > > > >(which must happen, because InputStream as defined is less usable) > > Not true. Either we follow the InputSteam specification or we define > our own interface. Breaking the specification in this way will trigger > unpredictable bugs. First, I disagree that it is specification because it actually is documentation. A specification would also need to specify how overloaded methods are allowed to change without violating the specification. If javadoc in general would be no documentation but specification obviously no overloaded method could specialise or change any behavior, because as soon as documentation of an overloaded would be needed, it would violate base class specification, in short, no new specification (documentation) could be allowed in any subclass. Theoretically this could be a point (an option to develop a language) but I think it makes not much sense in practice. Also, it often happens that even in specifications there are obvious issues, as soon as everyone does the obvious thing, instead of changing all implementations, the specification is fixed. Or left as it is :) Of course we define an own interface by deriving (implementing) InputStream because specifics will happen. For instance specialised exceptions may be thrown in special new situations not documented (specified) by InputStream. This is what OO is for I think. :) > Actually, the Javadoc for read(byte[]) says that at least one > byte must be read: "If the length of b is zero, then no bytes > are read and 0 is returned; otherwise, there is an attempt to > read at least one byte. If no byte is available because the > stream is at the end of the file, the value -1 is returned; > otherwise, at least one byte is read and stored into b." Strictly speaking, at least for me with my limited foreign language English knowledge, it does not tell what happens if an attempt to read at least one byte was done, no byte was available, the stream is NOT at the end of the file, but still no byte was read. I would accept the point that, strictly speaking, InputStream unconditionally forbids any timeout support (except polling available(), which at least sucks). This actually was my initial point. This prohibition makes no sense and probably was just done by accident (otherwise, docu should tell this) and also is violated if throwing exceptions and also is violated by Java stuff itself. > Fair enough, but "timeouts in a loop" -- using available() -- > don't break the InputStream specification. Yes, and somewhere probably there is some guy who defined InputStream as an Aprils Fool Joke and now cannot sleep because laughing about all those people that poll available() all the time (no delay to gain response time) wasting all CPU resources :-) Anyway, since years InputStream is used and I don't think we can do anything against. I also don't like it, but that's life. If you want a nice language use C++ or Ruby or so ;) SCNR. > >NIO is a bit more BSD socket API style, a step into the direction > >where everything comes from. Next version might take another step > >and reach the goal. Who knows. As far as I know none of the > >issues that lead to NIO (mostly performance and scalability) > >apply to rxtx. > > NIO allows you to select() on a channel with a timeout, which > is the point of contention. Yes, but not if the channel is some InputStream like STDIN, right? Also, as far as I know, you cannot select on own things. So wouldn't work for serial lines or protocols. I think you cannot implement TCP via PPP reasonable and efficiently in (pure) Java, even with NIO as far as I know this is not possible. But there are many things in Java that you cannot implement in Java (even String!). A pitty but otherwise things would be horrible slow. > I'm not sure I understand. I get that you dislike that > InputStream doesn't provide facilities for non-blocking reads > but that is just life. You're supposed to either create your > own interface or use NIO for that. In my view, breaking the > superclass contract is always worse than inconveniencing > yourself. I think, when we would discuss NIO, we would also quickly find sufficient issues with it (I think we had this discussion already) and that we do not (really :)) break the superclass contract (of InputStream). We just add possibility to support timeout (by new method setReceiveTimeout() and overloaded read()). :-) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed May 20 07:40:03 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 20 May 2009 15:40:03 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> Message-ID: <20090520134002.GC27170@elberon.bln.de.ingenico.com> (OT) * Kustaa Nyholm wrote on Wed, May 20, 2009 at 15:03 +0300: > Ever wondered why EOF is signaled with -1 and not an exception... Yeah... I always wonder why Java has so many issues that were already discussed and solved since ages in POSIX or ANSI-C or C++ /before/ java was started. On POSIX reads -1 is error. You call some select(2) before. If select tells ready-for-read and you read EOF, read returns 0 bytes. This is at least a bit intuitive - and seems to work in all cases. Seeing a file descriptor like a class IMHO works. read(fd, ..) could be understood as fd.read(). When looking how great in overall this works I feel deep respect for all the people who invented that :) > > Java places emphasizes correctness above performance. This is definitely wrong. Much of Java Core Tech is uglyDirtyNasty because of performance. For instance you cannot overload String (reasonable). Operator overloading is not possible except for String.operator+ (concatenation). Implicite conversion is possible by Object().toString() but nowhere else. You cannot implement a toLong() and have it be called implicitely. String automatically uses StringBuffer for operations, again a hack you have no chance to copy or influence. You cannot pass scalars like long by reference, you are force to pass them by value. You cannot pass Objects by value, you are forced to pass them by reference. Except your object is e.g. a Long, then it is passed by value. You cannot implement any of that in Java itself. It is Mr. JVM in person :) who knows those hacks and how to workaround / pass by. Also great is Object.clone(). Works without overloading. How does Object.clone() know the members of the child class? Because it knows the structure and hacks it to match. Same for serialisation and deserialisation. Object construction. Why can an Object call a method overloaded in a child class in its constructor? Interesting is what happens: the child class is already `half constructed', i.e. working except member initialisation and its constructor was not run. But a method can be invoked. This is not clean this sucks but anyway. We could continue this quite some time (Inner Class hacks, Generics hacks, forced GC, no RAII support would be next) :-) Honestly, a student would not pass a university test with so much hacking (I hope ;)). oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From michael.erskine at ketech.com Wed May 20 07:45:13 2009 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 20 May 2009 14:45:13 +0100 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0D6BA5.8020209@bbs.darktech.org> References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <06BA3262D918014F9183B66425D5A8D463C3C2E90A@no-sv-03.ketech.local> I wander in to find a gazillion posts about whether RXTX is breaking some rule or other. I don't have time to read and argue the toss over which way of doing something may be more correct. As far as I'm concerned (and, I venture, the other developers in industry) whatever RXTX does _IS_ the right thing. I don't fancy trying to justify the costs that would be incurred in the respecifying, rewriting, and retesting of an absolute ton of SIL2 software. Please, let's not screw things up. Regards, Michael Erskine. From Kustaa.Nyholm at planmeca.com Wed May 20 07:58:12 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 16:58:12 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090520134002.GC27170@elberon.bln.de.ingenico.com> Message-ID: Just to clarify Steffen's mail, this was not my sentence: >>> Java places emphasizes correctness above performance. to which he responded: > > This is definitely wrong. Much of Java Core Tech is > uglyDirtyNasty because of performance. > > Honestly, a student would not pass a university test with so much > hacking (I hope ;)). > and with which I agree. cheers Kusti From Kustaa.Nyholm at planmeca.com Wed May 20 08:13:54 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 17:13:54 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <06BA3262D918014F9183B66425D5A8D463C3C2E90A@no-sv-03.ketech.local> Message-ID: Michael Erskine: > I wander in to find a gazillion posts about whether RXTX is breaking some rule > or other. I don't have time to read and argue the toss over which way of doing > something may be more correct. I've participated in the discussion just for that reason, trying to prevent anyone 'correcting' this API. > > As far as I'm concerned (and, I venture, the other developers in industry) > whatever RXTX does _IS_ the right thing. Indeed! > > I don't fancy trying to justify the costs that would be incurred in the > respecifying, rewriting, and retesting of an absolute ton of SIL2 software. > Hear, hear! > Please, let's not screw things up. Yeah, let's not screw this up. From cowwoc at bbs.darktech.org Wed May 20 08:40:11 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 10:40:11 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090520132339.GB27170@elberon.bln.de.ingenico.com> References: <4A131674.6000906@bbs.darktech.org> <20090520083008.GH17036@elberon.bln.de.ingenico.com> <4A13DDE3.8070703@bbs.darktech.org> <20090520132339.GB27170@elberon.bln.de.ingenico.com> Message-ID: <4A14164B.6040000@bbs.darktech.org> Steffen DETTMER wrote: > First, I disagree that it is specification because it actually is > documentation. A specification would also need to specify how > overloaded methods are allowed to change without violating the > specification. If javadoc in general would be no documentation > but specification obviously no overloaded method could specialise > or change any behavior, because as soon as documentation of an > overloaded would be needed, it would violate base class > specification, That is incorrect. Design by Contract allows subclasses to weaken preconditions, strengthen postconditions and strengthen invariants -- all without violating the superclass specification. > Also, it often happens that even in specifications there are > obvious issues, as soon as everyone does the obvious thing, > instead of changing all implementations, the specification is > fixed. Or left as it is :) As far as I know, this has never been done for core Java classes because doing so would break backwards compatibility. This is discussed at length in the Effective Java book. > Of course we define an own interface by deriving (implementing) > InputStream because specifics will happen. For instance > specialised exceptions may be thrown in special new situations > not documented (specified) by InputStream. This is what OO is for > I think. :) A subclass may not throw any new (checked) exceptions. Doing so would violating the superclass specification. You could always throw a subclass of IOException but that's about it. The reason this only applies to checked exceptions is that all methods throw RuntimeException by default. >> Actually, the Javadoc for read(byte[]) says that at least one >> byte must be read: "If the length of b is zero, then no bytes >> are read and 0 is returned; otherwise, there is an attempt to >> read at least one byte. If no byte is available because the >> stream is at the end of the file, the value -1 is returned; >> otherwise, at least one byte is read and stored into b." > > Strictly speaking, at least for me with my limited foreign > language English knowledge, it does not tell what happens if an > attempt to read at least one byte was done, no byte was > available, the stream is NOT at the end of the file, but still no > byte was read. The sentence above reads "This method blocks until input data is available, end of file is detected, or an exception is thrown." In other words, you must block. > I would accept the point that, strictly speaking, InputStream > unconditionally forbids any timeout support (except polling > available(), which at least sucks). > > This actually was my initial point. This prohibition makes no > sense and probably was just done by accident (otherwise, docu > should tell this) and also is violated if throwing exceptions and > also is violated by Java stuff itself. If a timeout could be said to be a new kind of end-of-stream (with the resulting behavior being absolutely identical) then using -1 might be fine. Unfortunately, this is not the case. End-of-stream indicates that the InputStream will never return bytes ever again. Timeouts violate this guarantee. With respect to exceptions, you are allowed to throw any subclass of IOException for the reasons mentioned in Design by Contract. >> Fair enough, but "timeouts in a loop" -- using available() -- >> don't break the InputStream specification. > > Yes, and somewhere probably there is some guy who defined > InputStream as an Aprils Fool Joke and now cannot sleep because > laughing about all those people that poll available() all the > time (no delay to gain response time) wasting all CPU resources > :-) InputStream works perfectly fine for synchronous reading. If you want asynchronous reading you are supposed to use NIO channels. >> NIO allows you to select() on a channel with a timeout, which >> is the point of contention. > Yes, but not if the channel is some InputStream like STDIN, > right? Also, as far as I know, you cannot select on own things. > So wouldn't work for serial lines or protocols. I don't understand what you mean. You can get a Channel for System.in using java.nio.channels.Channels. > I think you cannot implement TCP via PPP reasonable and > efficiently in (pure) Java, even with NIO as far as I know this > is not possible. But there are many things in Java that you > cannot implement in Java (even String!). You can find TCP/PPP implementations in Java on the web. You don't need them most of the time because the OS provides an implementation for free. > I think, when we would discuss NIO, we would also quickly find > sufficient issues with it (I think we had this discussion > already) and that we do not (really :)) break the superclass > contract (of InputStream). We just add possibility to support > timeout (by new method setReceiveTimeout() and overloaded read()). Again, I suggest you read up on Design by Contract. You will find out exactly why you are not allowed to overload the -1 return code in this way. Gili From cowwoc at bbs.darktech.org Wed May 20 08:46:08 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 10:46:08 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <06BA3262D918014F9183B66425D5A8D463C3C2E90A@no-sv-03.ketech.local> References: <4A0D6BA5.8020209@bbs.darktech.org> <06BA3262D918014F9183B66425D5A8D463C3C2E90A@no-sv-03.ketech.local> Message-ID: <4A1417B0.3040903@bbs.darktech.org> Michael, You have a choice to either break compatibility with old versions of RXTX or break compatibility with all other libraries in existence. Both options suck, but the latter involves breaking even more code. Right now you cannot safely pass RXTX's InputStream into any other library in existence. Gili Michael Erskine wrote: > I wander in to find a gazillion posts about whether RXTX is breaking some rule or other. I don't have time to read and argue the toss over which way of doing something may be more correct. > > As far as I'm concerned (and, I venture, the other developers in industry) whatever RXTX does _IS_ the right thing. > > I don't fancy trying to justify the costs that would be incurred in the respecifying, rewriting, and retesting of an absolute ton of SIL2 software. > > Please, let's not screw things up. > > Regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From johnny.luong at trustcommerce.com Wed May 20 09:55:03 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Wed, 20 May 2009 08:55:03 -0700 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> Message-ID: <4A1427D7.2020906@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Trent Jarvi wrote: | On Tue, 19 May 2009, cowwoc wrote: |>> A time out in a serial communication is |>> almost always to be excepted since it is used to deal with real, live |>> hardware outside the computer |> I disagree. Some application-level protocols don't use timeouts at all. |> Why would your argument be true for serial connections but not sockets? |> | | Hi Gili | | One fundamental difference between sockets, file io and RS232 | communication is that sockets and file systems provide error handling. | If a packet is lost, it is resent without the java API knowing about it. | | RS232 is actually an electrical signal standard. Serial communication | exposes a UART without any meaningful error handling and cludgy error | reporting. | | Given the above, ignoring timeouts is not really a valid rxtx level | option. We could have a new option/method that allows you to get an | InputStream or Channel that behaves as you wish. | | If we change the InputStream returned by getInputStream(), that would | be change in the API (version 3.0) that forks our userbase. | | So I guess my question is whether or not you are trying to change the | object returned by getInputStream or just looking for a means to get a | different object you would like to define be returned. | | The later is far easier to accommodate. | | -- | Trent Jarvi | tjarvi at qbang.org | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Trent, For sockets, I'm not so sure there is really any guarantees short of actually monitoring it externally. For example, write() in outputstream doesn't return any value whatsoever -- you might get an exception but in the worse case, it just tells you something bad happened and in the best case, you might be able to catch some implementation specific exception. ~ The same could apply to files too but the magnitude of failure there are significantly lower. But this is sort of a digression... My thinking is that we just sort of keep the interface so that we don't disrupt people who use the methods (our software actually polls from the serial port version of the InputStream/OutputStream as a side effect of the quirkyness involved with the timeout -- this is because the USB-serial thing we had to work with really sucks) but add an additional interface similar to what is SocketChannel and proceed from there. There is a lot of work involved in it though and as it has been pointed out by others, maybe most can live with the hacks involved in the current implementation. Best, Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoUJ9cACgkQnQTBLXttTeVYlQCfcvIHMh1W1kcna5vUtg20dWWK flMAn2WZk03PSgYT1KkHMLp8TlLRtcxn =YeMI -----END PGP SIGNATURE----- From michaeltandy at googlemail.com Wed May 20 09:57:36 2009 From: michaeltandy at googlemail.com (Michael Tandy) Date: Wed, 20 May 2009 16:57:36 +0100 Subject: [Rxtx] Rxtx native library loading In-Reply-To: References: <302aa0340905190733r4009e394v335b3ef47d84ffb5@mail.gmail.com> Message-ID: <302aa0340905200857v53642f58je6932c3315b8a30d@mail.gmail.com> There's also a bug in my code; it worked fine swapping between my Windows machine and my 64-bit Linux machine, but trying to run the 64-bit library on my 32-bit Linux laptop (obviously) doesn't work. So, it needs to detect more architectures and handle them more cleverly :) Still, if your next release will do that, I guess I don't have to fix my code :) Thanks Michael 2009/5/20 Trent Jarvi : > > Hi Michael, > > We will be putting a patch like yours in as soon as we release 2.2. ?The > release was going to be mothers day but I got caught up :) ?I hope to do it > next weekend. ?After that we will be looking at web installs which overlaps > with your solution. > > -- > Trent Jarvi > tjarvi at qbang.org > From cowwoc at bbs.darktech.org Wed May 20 10:04:32 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 12:04:32 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A1427D7.2020906@trustcommerce.com> References: <4A131674.6000906@bbs.darktech.org> <4A1427D7.2020906@trustcommerce.com> Message-ID: <4A142A10.1090302@bbs.darktech.org> Johnny Luong wrote: > My thinking is that we just sort of keep the interface so that we don't > disrupt people who use the methods (our software actually polls from the > serial port version of the InputStream/OutputStream as a side effect of > the quirkyness involved with the timeout -- this is because the > USB-serial thing we had to work with really sucks) but add an additional > interface similar to what is SocketChannel and proceed from there. We could also deprecate getInputStream() in favor of another method that returns a fixed implementation. This will allow existing code to keep on working while providing a migration route for RXTX 3.0. Gili From jerrypedersen at telus.net Wed May 20 10:10:00 2009 From: jerrypedersen at telus.net (Jerry Pedersen) Date: Wed, 20 May 2009 09:10:00 -0700 Subject: [Rxtx] 38400 Baud - UnsupportedCommOperationexception: Invalid Parameter Message-ID: <4A142B58.4050909@telus.net> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090520/0ac89fb9/attachment-0004.html From bill7007 at gmail.com Wed May 20 11:20:13 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Wed, 20 May 2009 13:20:13 -0400 Subject: [Rxtx] 38400 Baud - UnsupportedCommOperationexception: Invalid Parameter In-Reply-To: <4A142B58.4050909@telus.net> References: <4A142B58.4050909@telus.net> Message-ID: Hi Jerry, You might check out: [Rxtx] Baud rate fixes in 2.2pre2 breaks 38400 on some Linux devices It has a link to a patch on 2.2pre that got me around a similar problem. +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090520/046aa29d/attachment-0004.html From Kustaa.Nyholm at planmeca.com Wed May 20 12:23:41 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 21:23:41 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A1417B0.3040903@bbs.darktech.org> References: <4A0D6BA5.8020209@bbs.darktech.org> <06BA3262D918014F9183B66425D5A8D463C3C2E90A@no-sv-03.ketech.local>, <4A1417B0.3040903@bbs.darktech.org> Message-ID: <5D23E5B41156B646B2E1A7C2BBA916F317119151AF@SRVFIHKIEXB01.pmgroup.local> Gili wrote: >You have a choice to either break compatibility with old versions of >RXTX or break compatibility with all other libraries in existence. Both >options suck, but the latter involves breaking even more code. Or, the third option, leave it well alone! Keep it compatible existing code that is actually using rxtx instead of just worrying about it being correct to a T. Use it as the creators meant it to be used. Stop worrying about this. > Right now you cannot safely pass RXTX's InputStream into any other >library in existence. Now that is blatantly untrue. If timeouts are not enable you can pass it safely to any library. When timeouts are enabled *some* libraries will not work, some will. If you worry or encounter such a situation you can then do some wrapper magic. But for pete's sake, let us not disturb the happy life of rxtx users with well intentioned but misguided zealozy. I wonder too how often SerialPort input stream is passed to *any* library? I certainly haven't done that ever. The way I vision people are using serial port is to talk directly to it doing most if not all of the protocol handling with custom code, not with a library. If pass it (the input stream) to a library that chokes on read returning 0 it is rather your fault for not reading what the javadoc for SerialPort.getInputStream says! cheers Kusti From tjarvi at qbang.org Wed May 20 17:18:37 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 May 2009 17:18:37 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A142A10.1090302@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> <4A1427D7.2020906@trustcommerce.com> <4A142A10.1090302@bbs.darktech.org> Message-ID: On Wed, 20 May 2009, cowwoc wrote: > Johnny Luong wrote: >> My thinking is that we just sort of keep the interface so that we don't >> disrupt people who use the methods (our software actually polls from the >> serial port version of the InputStream/OutputStream as a side effect of >> the quirkyness involved with the timeout -- this is because the >> USB-serial thing we had to work with really sucks) but add an additional >> interface similar to what is SocketChannel and proceed from there. > > We could also deprecate getInputStream() in favor of another method > that returns a fixed implementation. This will allow existing code to > keep on working while providing a migration route for RXTX 3.0. > Hi Gili, Good. I think it is time to see the method and InputStream. From there, we can discuss options in 3.0. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Wed May 20 18:49:50 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 20:49:50 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> <4A1427D7.2020906@trustcommerce.com> <4A142A10.1090302@bbs.darktech.org> Message-ID: <4A14A52E.7080701@bbs.darktech.org> Trent Jarvi wrote: > Good. > > I think it is time to see the method and InputStream. From there, we > can discuss options in 3.0. I propose the following: 1) add "CommPortChannel getChannel()" 2) deprecate getInputStream() and enableReceiveTimeout() in favor of getChannel() 3) getChannel() will return a class that implements the same interfaces as SocketChannel. It will allow both blocking and non-blocking I/O operations. 4) In RXTX 3.0 getInputStream() will return an InputStream that always blocks on reads and the method will be undeprecated. Gili From tjarvi at qbang.org Wed May 20 19:27:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 May 2009 19:27:50 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A14A52E.7080701@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> <4A1427D7.2020906@trustcommerce.com> <4A142A10.1090302@bbs.darktech.org> <4A14A52E.7080701@bbs.darktech.org> Message-ID: On Wed, 20 May 2009, cowwoc wrote: > Trent Jarvi wrote: >> Good. >> >> I think it is time to see the method and InputStream. From there, we can >> discuss options in 3.0. > > I propose the following: > > 1) add "CommPortChannel getChannel()" > 2) deprecate getInputStream() and enableReceiveTimeout() in favor of > getChannel() > 3) getChannel() will return a class that implements the same interfaces as > SocketChannel. It will allow both blocking and non-blocking I/O operations. > 4) In RXTX 3.0 getInputStream() will return an InputStream that always blocks > on reads and the method will be undeprecated. > Hi Gili, RXTX 3.0 would be the soonest we would start any deprecation if it is agreed upon. So far, I don't think there is near enough buy in. But you can have getChannel now. If it is obviously a right solution, you may see people reconsider their opinions. Timeouts wont go away or be deprecated but they could throw unsupported io exceptions for the life of the inputstream returned by getChannel for obvious reasons. Let people try it and give feedback. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Thu May 21 01:19:05 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 21 May 2009 10:19:05 +0300 Subject: [Rxtx] InputStream timeouts Message-ID: <5D23E5B41156B646B2E1A7C2BBA916F317119151B4@SRVFIHKIEXB01.pmgroup.local> Hi Gili, please don't start patronizing. I've been around OO and Design by Contract from around 1986 starting by implementing our own Smalltalk environment. By then I had been writing software for ten years. It is not that I don't understand what you are saying. It is just that I'm not (any more ?!) an OO or DbC zealot. In real world most concepts seem to break down when applied over too wide field. Newtons laws are fine until you get to quantum level. OO is great, but at least so far, it seems that making everything (think integers) objects was a mistake in Smalltalk. You maybe right on the theoretical level, but who cares? Who are you to impose *your* standards on the rest of us? *Every good desing is a compromize.* In this instance I'm 100% sure that the designers of javacomm were well aware of the issues you are complaining about and considered these and many other issues. And their compromise is what we have today.It would belittling them to think otherwise. And to me, even if I think I see where you are coming from, the compromise seem almost perfect for the given problem. To me it is very natural and works almost perfectly despite (or because ?) of the little bending of the rules. Like Steffen(?) wrote here earlier : that (compromise to make it work) is Java all over. And I firmly believe that that is what made Java a success, just like C. Not the prettiest girls in town but very popular... cheers Kusti ________________________________________ From: cowwoc [cowwoc at bbs.darktech.org] Sent: Wednesday, May 20, 2009 9:42 PM To: Kustaa Nyholm Subject: Re: [Rxtx] InputStream timeouts Do me a favor and let me know once you read about Design by Contract. Only then will you be able to understand why RXTX cannot redefine how InputStream works. If subclasses are allowed to modify the contract in an arbitrary manner it defeats the entire concept of Class Inheritance and formal Interfaces. Gili Kustaa Nyholm wrote: > Gili wrote: > >> You have a choice to either break compatibility with old versions of >> RXTX or break compatibility with all other libraries in existence. Both >> options suck, but the latter involves breaking even more code. > > Or, the third option, leave it well alone! Keep it compatible existing code > that is actually using rxtx instead of just worrying about it being correct > to a T. Use it as the creators meant it to be used. Stop worrying about > this. > > >> Right now you cannot safely pass RXTX's InputStream into any other >> library in existence. > > Now that is blatantly untrue. If timeouts are not enable you can pass > it safely to any library. When timeouts are enabled *some* libraries will > not work, some will. If you worry or encounter such a situation you > can then do some wrapper magic. But for pete's sake, let us not disturb > the happy life of rxtx users with well intentioned but misguided zealozy. > > I wonder too how often SerialPort input stream is passed to *any* library? > > I certainly haven't done that ever. > > The way I vision people are using serial port is to talk directly to it > doing most if not all of the protocol handling with custom code, > not with a library. If pass it (the input stream) to a library that chokes on > read returning 0 it is rather your fault for not reading what > the javadoc for SerialPort.getInputStream says! > > cheers Kusti > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Kustaa.Nyholm at planmeca.com Thu May 21 01:20:42 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 21 May 2009 10:20:42 +0300 Subject: [Rxtx] InputStream timeouts Message-ID: <5D23E5B41156B646B2E1A7C2BBA916F317119151B5@SRVFIHKIEXB01.pmgroup.local> Gili wrote: >You have a choice to either break compatibility with old versions of >RXTX or break compatibility with all other libraries in existence. Both >options suck, but the latter involves breaking even more code. Or, the third option, leave it well alone! Keep it compatible existing code that is actually using rxtx instead of just worrying about it being correct to a T. Use it as the creators meant it to be used. Stop worrying about this. > Right now you cannot safely pass RXTX's InputStream into any other >library in existence. Now that is blatantly untrue. If timeouts are not enable you can pass it safely to any library. When timeouts are enabled *some* libraries will not work, some will. If you worry or encounter such a situation you can then do some wrapper magic. But for pete's sake, let us not disturb the happy life of rxtx users with well intentioned but misguided zealozy. I wonder too how often SerialPort input stream is passed to *any* library? I certainly haven't done that ever. The way I vision people are using serial port is to talk directly to it doing most if not all of the protocol handling with custom code, not with a library. If pass it (the input stream) to a library that chokes on read returning 0 it is rather your fault for not reading what the javadoc for SerialPort.getInputStream says! cheers Kusti From Kustaa.Nyholm at planmeca.com Thu May 21 01:49:36 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 21 May 2009 10:49:36 +0300 Subject: [Rxtx] InputStream timeouts - opinions on breaking compatibility? Message-ID: <5D23E5B41156B646B2E1A7C2BBA916F317119151B6@SRVFIHKIEXB01.pmgroup.local> Hi, changed the subject line a bit because I suspect most people have tuned out of this discussion and yet I feel that it is the very people who's input is needed. A month or so ago a lot of people chimed in by telling *what* they do with rxtx, now I would really be interesting to know *how* people are using rxtx? More specifically and relevant to this discussion: 1) are timeouts used? 2) how are they handled? 3) are SerialPort InputStreams passed to library functions? 4) have there been problems (in 3 above)? 5) how would you feel if you would need to rework your code to work with the 'improved' API? The proposal we have (by Gili) is: > 1) add "CommPortChannel getChannel()" This I do not mind so much as I do not need to touch my code. > 2) deprecate getInputStream() and enableReceiveTimeout() in favor of > getChannel() This I object to very much. One of my coding 'rules' say do-not-use-deprecated methods. An other rule says that my compiles-should-be-clean, so this would need me to change my code. Also, this is imposing and force feeding things to people who can't appreciate the beauty of the 'improvements' and are against them. > 3) getChannel() will return a class that implements the same interfaces as > SocketChannel. It will allow both blocking and non-blocking I/O operations. As I will not be using that (getChannel()) I don't care so much, but I bet this will be a new can worms having just the same sort of issues and compromises as we have been discussing here. But it would really be educational and fun to see proposers eat their own dog meat, so yes, let's do this! > 4) In RXTX 3.0 getInputStream() will return an InputStream that always blocks > on reads and the method will be undeprecated. > Just great, this is the top, I'm totally against this. Not only did (2) above require me to rework my code but now in phase two I would need to rework my code again to comply with yet another API change. There has to be better things in life and coding than tracking ever changing APIs! I'm involved in several projects ranging from a few thousand lines to several thousand hand written classes. Javacomm and rxtx play a small but crucial part in these. I would very much like to spend time on improving the applications instead of tracking changes in different APIs (not limited to rxtx). Especially changes that IMO only bring internal beauty . Our current code works and has been debugged to with the current API design, no compelling reason has been put forward to change the API and throw away the (albeit not so big) investment in learning to use the current API and making our code to work with it. All I care is that I have a cross platform serial port API that is stable and works as advertised, and which I do not have to implement and test on all the platforms. So far rxtx has been just wonderful, let's keep it that way. my 2 snt worth, cheers Kusti From michaeltandy at googlemail.com Thu May 21 05:48:44 2009 From: michaeltandy at googlemail.com (Michael Tandy) Date: Thu, 21 May 2009 12:48:44 +0100 Subject: [Rxtx] Buffer overflow caused by fhs_lock error message Message-ID: <302aa0340905210448v46b7ee61j58787b10500411b@mail.gmail.com> When, on Linux, one attempts to open a device such as /dev/ttyUSB71 and the device is locked, Java crashes with this error message: *** buffer overflow detected ***: java terminated ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7ead6d8] /lib/tls/i686/cmov/libc.so.6[0xb7eab800] /lib/tls/i686/cmov/libc.so.6[0xb7eaaef8] /lib/tls/i686/cmov/libc.so.6(_IO_default_xsputn+0xc8)[0xb7e20a78] /lib/tls/i686/cmov/libc.so.6(_IO_vfprintf+0x6f3)[0xb7df30b3] /lib/tls/i686/cmov/libc.so.6(__vsprintf_chk+0xa4)[0xb7eaafa4] /lib/tls/i686/cmov/libc.so.6(__sprintf_chk+0x2d)[0xb7eaaeed] /home/michael/Documents/asdf/lib/librxtxSerial.so(fhs_lock+0x1c2)[0xb4b82cf2] /home/michael/Documents/asdf/lib/librxtxSerial.so(Java_gnu_io_RXTXCommDriver_testRead+0x80)[0xb4b838a0] This is caused because trying to sprintf the error message, the device name, the error description, the newline and then null terminate the string overflows the 80 characters allocated. The problem code seems to be: char message[80]; sprintf( message,"RXTX fhs_lock() Error: creating lock file: %s: %s\n", file, strerror(errno) ); A switch to the buffer-overflow-proof snprintf function fixes the problem by truncating the error message if it exceeds 79 characters: char message[80]; snprintf( message, 80, "RXTX fhs_lock() Error: creating lock file: %s: %s\n", file, strerror(errno) ); A patch is attached to apply this fix - although there might be other bugs of this class in rxtx; it might be worth applying this fix anywhere sprintf is currently used. Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: overflowpatch.diff Type: application/octet-stream Size: 1133 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090521/3a487d21/attachment-0004.obj From rxtx at qbang.org Thu May 21 09:48:47 2009 From: rxtx at qbang.org (VIAGRA ® Official Site) Date: Thu, 21 May 2009 09:48:47 -0600 Subject: [Rxtx] Dear rxtx@qbang.org SALE 77% 0FF on Pfizer ! Message-ID: <200905211548.n4LFmltZ029873@rxtx.qbang.org> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090521/c9af7fb9/attachment-0003.html From Klaus.Kierer at Tiscover.com Thu May 21 10:02:52 2009 From: Klaus.Kierer at Tiscover.com (Kierer, Klaus) Date: Thu, 21 May 2009 18:02:52 +0200 Subject: [Rxtx] Abwesenheitsnotiz: URL Filtering: Re: Dear rxtx@qbang.org SALE 77% 0FF on Pfizer ! Message-ID: <65FE44E2CAED5742B96A161F3703A5390861B0F5@ibk-tis-mx-01.tiscover.corp> Vielen Dank f?r Ihre Nachricht. Ich bin leider bis Montag, 25 Mai au?er Haus und werde mich erst anschlie?end um Ihr Anliegen k?mmern k?nnen. In dringenden F?llen senden Sie daher bitte ein Email an alexander.sommer at tiscover.com. Danke. Mit freundlichen Gr??en Klaus Kierer www.tiscover.com Thank you for your message. I am currently not contactable until Monday, 25th of May and thus cannot respond to your message until then. If your enquiry is urgent, please contact alexander.sommer at tiscover.com. Thank you. Kind Regards Klaus Kierer www.tiscover.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090521/0d4f9c57/attachment-0003.html From pixue_breaker at hotmail.com Fri May 22 02:35:41 2009 From: pixue_breaker at hotmail.com (=?iso-8859-1?Q?Samuel_Ovia=F1o_Su=E1rez?=) Date: Fri, 22 May 2009 08:35:41 +0000 Subject: [Rxtx] porting rxtx to avr32-linux Message-ID: Hi! I'm trying to port rxtx to avr32-linux. My objetive is executing a serial comm app with jamvm running on avr32-linux platform so i need the suitable librxtxSerial.so for this. I have started to work in that following the next steps: 1. input : ./autogen.sh --host=avr32-linux --target=avr32-linux output : You should update your `aclocal.m4' by running aclocal acinclude.m4:6193: the serial number must appear before any macro definition 2. I updated aclocal comment out line 6193 of acinlcude.m4 and then i typed 'aclocal' 3. input: ./configure --host=avr32-linux --target=avr32-linux output: the makefile with avr32-linux settings After, i tried to 'make install' but compilation process stopped with this error: /home/samuel/Escritorio/rxtx-2.1-7r2/./src/SerialImp.h:441: error: expected declaration specifiers or '...' before 'wchar_t' avr32-linux-gcc -I/home/samuel/Escritorio/rxtx-2.1-7r2 -Iavr32-unknown-linux-gnu -I. -I/usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/include -I/usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/include/./ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c /home/samuel/Escritorio/rxtx-2.1-7r2/./src/fuserImp.c -fPIC -DPIC -o /home/samuel/Escritorio/rxtx-2.1-7r2/avr32-unknown-linux-gnu/.libs/fuserImp.o libtool: link: `/home/samuel/Escritorio/rxtx-2.1-7r2/avr32-unknown-linux-gnu/SerialImp.lo' is not a valid libtool object make: *** [avr32-unknown-linux-gnu/librxtxSerial.la] Error 1 What's wrong? Thanks in advance, Pixueto _________________________________________________________________ ?Qu?tate unos clics! Ahora, Internet Explorer 8 tiene todo lo que te gusta de Windows Live ?Cons?guelo gratis! http://ie8.msn.com/microsoft/internet-explorer-8/es-es/ie8.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090522/87e7bc4d/attachment-0003.html From tjarvi at qbang.org Fri May 22 09:05:44 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 May 2009 09:05:44 -0600 (MDT) Subject: [Rxtx] porting rxtx to avr32-linux In-Reply-To: References: Message-ID: On Fri, 22 May 2009, Samuel Ovia?o Su?rez wrote: > Hi! > > I'm trying to port rxtx to avr32-linux. My objetive is executing a serial comm app with jamvm running on avr32-linux platform so i need the suitable > librxtxSerial.so for this. I have started to work in that following the next steps: > > 1. input : ./autogen.sh --host=avr32-linux --target=avr32-linux > ??? output : You should update your `aclocal.m4' by running aclocal > ?????????????????? acinclude.m4:6193: the serial number must appear before any macro definition > > 2. I updated aclocal comment out line 6193 of acinlcude.m4 and then i typed 'aclocal' > > 3. input: ./configure --host=avr32-linux --target=avr32-linux > ??? output: the makefile with avr32-linux settings > > After, i tried to 'make install' but compilation process stopped with this error: > > /home/samuel/Escritorio/rxtx-2.1-7r2/./src/SerialImp.h:441: error: expected declaration specifiers or '...' before 'wchar_t' > ?avr32-linux-gcc -I/home/samuel/Escritorio/rxtx-2.1-7r2 -Iavr32-unknown-linux-gnu -I. -I/usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/include > -I/usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/include/./ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c > /home/samuel/Escritorio/rxtx-2.1-7r2/./src/fuserImp.c? -fPIC -DPIC -o /home/samuel/Escritorio/rxtx-2.1-7r2/avr32-unknown-linux-gnu/.libs/fuserImp.o > libtool: link: `/home/samuel/Escritorio/rxtx-2.1-7r2/avr32-unknown-linux-gnu/SerialImp.lo' is not a valid libtool object > make: *** [avr32-unknown-linux-gnu/librxtxSerial.la] Error 1 > > What's wrong? > > Thanks in advance, Hi Pixueto I don't think autogen.sh takes arguments. Perhaps you are used to a newer version of the same script. The arguments should be ignored. .m4 files are beyond me. Your hack is typical of what I do but I've not made rules before. Is line 441 in SerialImp.h 'extern int mexPrintf( const char *, ... );" ? If so, you do not want to turn on DEBUG_MW. Those functions are an older way of printing debug information in MATLAB. -- Trent Jarvi tjarvi at mathworks.com From Bob_Jacobsen at lbl.gov Fri May 22 10:05:12 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Fri, 22 May 2009 09:05:12 -0700 Subject: [Rxtx] InputStream timeouts - opinions on breaking compatibility? In-Reply-To: <5D23E5B41156B646B2E1A7C2BBA916F317119151B6@SRVFIHKIEXB01.pmgroup.local> References: <5D23E5B41156B646B2E1A7C2BBA916F317119151B6@SRVFIHKIEXB01.pmgroup.local> Message-ID: At 10:49 AM +0300 5/21/09, Kustaa Nyholm wrote: >A month or so ago a lot of people chimed in by telling *what* they >do with rxtx, >now I would really be interesting to know *how* people are using rxtx? > >More specifically and relevant to this discussion: > >1) are timeouts used? Yes, because on some platforms/protocols it's the only known way to get the last read character. >2) how are they handled? Just repeat the read >3) are SerialPort InputStreams passed to library functions? Yes. >4) have there been problems (in 3 above)? No. >5) how would you feel if you would need to rework your code to work >with the 'improved' API? If you changed the API? Very, very unhappy. >The proposal we have (by Gili) is: > > > 1) add "CommPortChannel getChannel()" > No objection, but no plans to use on any reasonable timescale. > > 2) deprecate getInputStream() and enableReceiveTimeout() in favor of > > getChannel() > You should only deprecate something you intend to eventually remove. What's the reason to _remove_ these? They do what they do. > > 3) getChannel() will return a class that implements the same interfaces as > > SocketChannel. It will allow both blocking and non-blocking I/O operations. > If this is going to be done, somebody should _first_ write a very detailed API of what the SocketChannel interface "means" for serial communications (which isn't just bytes and EOF). > > 4) In RXTX 3.0 getInputStream() will return an InputStream that >always blocks >> on reads and the method will be undeprecated. >> Very, very opposed to this. If you want to provide another interface, fine, but don't hijack an existing one. This will result in significant maintenance problems as people have to mix and match various versions of RXTX for concurrent use. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From cowwoc at bbs.darktech.org Fri May 22 10:29:39 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 22 May 2009 12:29:39 -0400 Subject: [Rxtx] InputStream timeouts - opinions on breaking compatibility? In-Reply-To: References: <5D23E5B41156B646B2E1A7C2BBA916F317119151B6@SRVFIHKIEXB01.pmgroup.local> Message-ID: <4A16D2F3.2000607@bbs.darktech.org> Bob Jacobsen wrote: >> 3) are SerialPort InputStreams passed to library functions? > > Yes. Related question: which classes do you pass RXTX's InputStream to? Gili From pixue_breaker at hotmail.com Sat May 23 11:35:51 2009 From: pixue_breaker at hotmail.com (=?iso-8859-1?Q?Samuel_Ovia=F1o_Su=E1rez?=) Date: Sat, 23 May 2009 17:35:51 +0000 Subject: [Rxtx] porting rxtx to avr32-linux Message-ID: Hi!, I think i achieve complete the porting. I followed the next steps: - At SerialImp.h , comment out line 441 - At I2CImp.c , comment out lines 96 to 100 - At RawImp.c , comment out lines 240 to 244 and line 65 - At RS485Imp.c, comment out lines 96 to 100 Then i did make install and the output was the following: ---------------------------------------------------------------------- Libraries have been installed in: /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/jre/lib/i386 If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-Wl,--rpath -Wl,LIBDIR' linker flag - have your system administrator add LIBDIR to `/etc/ld.so.conf'See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. ---------------------------------------------------------------------- /usr/bin/install -c RXTXcomm.jar /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/jre/lib/ext/ /usr/bin/install: el destino, ?/usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/jre/lib/ext/?, no es un directorio: No existe el fichero ? directoriomake: *** [install] Error 1 This error its no important because its due to this fold doest exist and cant install RXTXcomm.jar but doesnt matter. Next i copy native libraries to classpath. I tested a simple app that only print the serial ports. The execution was ok but no serial ports were printed, i was using serial port to comunicate pc with NGW100 trough a terminal, but the output of the app was null, no serial ports were found. I dont know whats the problem, do i need some adittional resources? Thanks for your help! Pixu _________________________________________________________________ ?Qu?tate unos clics! Ahora, Internet Explorer 8 tiene todo lo que te gusta de Windows Live ?Cons?guelo gratis! http://ie8.msn.com/microsoft/internet-explorer-8/es-es/ie8.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090523/c4640863/attachment.html From tjarvi at qbang.org Sat May 23 17:08:33 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 May 2009 17:08:33 -0600 (MDT) Subject: [Rxtx] porting rxtx to avr32-linux In-Reply-To: References: Message-ID: On Sat, 23 May 2009, Samuel Ovia?o Su?rez wrote: > Hi!, > > I think i achieve complete the porting. I followed the next steps: > > - At SerialImp.h , comment out line 441 > - At I2CImp.c , comment out lines 96 to 100 > - At RawImp.c , comment out lines 240 to 244 and line 65 > - At RS485Imp.c, comment out lines 96 to 100 > > Then i did make install and the output was the following: > > ---------------------------------------------------------------------- > > Libraries have been installed in: > > /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/jre/lib/i386 > > > If you ever happen to want to link against installed libraries > > in a given directory, LIBDIR, you must either use libtool, and > > specify the full pathname of the library, or use the `-LLIBDIR' > > flag during linking and do at least one of the following: > > - add LIBDIR to the `LD_LIBRARY_PATH' environment variable > > during execution > > - add LIBDIR to the `LD_RUN_PATH' environment variable > > during linking > > - use the `-Wl,--rpath -Wl,LIBDIR' linker flag > > - have your system administrator add LIBDIR to `/etc/ld.so.conf' > > See any operating system documentation about shared libraries for > > more information, such as the ld(1) and ld.so(8) manual pages. > > ---------------------------------------------------------------------- > > /usr/bin/install -c RXTXcomm.jar > /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/jre/lib/ext/ > > /usr/bin/install: el destino, > ?/usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/jre/lib/ext/?, no es un directorio: > No existe el fichero ? directorio > > make: *** [install] Error 1 > > > This error its no important because its due to this fold doest exist and > cant install RXTXcomm.jar but doesnt matter. > > Next i copy native libraries to classpath. > > I tested a simple app that only print the serial ports. The execution was ok > but no serial ports were printed, i was using serial port to comunicate pc > with NGW100 > trough a terminal, but the output of the app was null, no serial ports were > found. I dont know whats the problem, do i need some adittional resources? > > Thanks Pixu, Which libc and version did you compile against? -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sat May 2 00:39:04 2009 From: luis.moreira at ntlworld.com (luis.moreira at ntlworld.com) Date: Sat, 2 May 2009 7:39:04 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Hi Travis, The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. The issues I still have is the errors after that. Do you have any idea what can be causing this errors? _______________________________________________________________________________ conftest.c: In function 'main': conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) conftest.c:8: error: (Each undeclared identifier is reported only once conftest.c:8: error: for each function it appears in.) conftest.c:8: error: expected ')' before string constant conftest.c:8: warning: format not a string literal and no format arguments ./configure: line 21462: ./conftest: No such file or directory ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands ------------------------------------------------------------------------------- I don't know what happened to my previous post, it as not showed up in the list. Best Regards Luis From tjarvi at qbang.org Sat May 2 07:30:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 07:30:04 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> References: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Message-ID: On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > Hi Travis, > The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. > The issues I still have is the errors after that. Do you have any idea what can be causing this errors? > > _______________________________________________________________________________ > conftest.c: In function 'main': > conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) > conftest.c:8: error: (Each undeclared identifier is reported only once > conftest.c:8: error: for each function it appears in.) > conftest.c:8: error: expected ')' before string constant > conftest.c:8: warning: format not a string literal and no format arguments > ./configure: line 21462: ./conftest: No such file or directory > ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: config.h is unchanged > config.status: executing depfiles commands > ------------------------------------------------------------------------------- > > This was corrected in CVS. I think you can just do the following in the top directory: cvs login: (pw is mousy) cvs update That will get the current fixes. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sat May 2 16:14:50 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sat, 02 May 2009 23:14:50 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FCC5DA.6000700@ntlworld.com> Trent Jarvi wrote: > > > On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > >> Hi Travis, >> The problem with the Makefile is not a problem,When I run ./configure >> I make a new Makefile with the same data in it, hence what I just >> modified is removed. >> The issues I still have is the errors after that. Do you have any >> idea what can be causing this errors? >> >> _______________________________________________________________________________ >> >> conftest.c: In function 'main': >> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >> function) >> conftest.c:8: error: (Each undeclared identifier is reported only once >> conftest.c:8: error: for each function it appears in.) >> conftest.c:8: error: expected ')' before string constant >> conftest.c:8: warning: format not a string literal and no format >> arguments >> ./configure: line 21462: ./conftest: No such file or directory >> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >> expected >> configure: creating ./config.status >> config.status: creating Makefile >> config.status: creating config.h >> config.status: config.h is unchanged >> config.status: executing depfiles commands >> ------------------------------------------------------------------------------- >> >> >> > > This was corrected in CVS. I think you can just do the following in > the top directory: > > cvs login: (pw is mousy) > cvs update > > That will get the current fixes. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, apologies for the mix-up of your name. I managed to get further on by updating CVS, the configure command gets to the end without any errors, it still warns me that it is confused about where to find the jni_md.h but I just edited the Makefile and sorted that out. I then run make, with no parameters following the instructions on the Wiki, but that generated a few more errors: ----------------------------------------------------------------------------------------------------------------------- gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. -I/usr/lib/jvm/java-6-openjdk/include /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' undeclared (first use in this function) /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared identifier is reported only once /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each function it appears in.) libtool: link: `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 ----------------------------------------------------------------------------------------------------------------------- Another question I have is, in which folder will the .so files be placed after make finishes? thank you very much for your help. Best Regards Luis From tjarvi at qbang.org Sat May 2 19:27:08 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 19:27:08 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FCC5DA.6000700@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> Message-ID: On Sat, 2 May 2009, Luis Moreira wrote: > Trent Jarvi wrote: >> >> >> On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: >> >>> Hi Travis, >>> The problem with the Makefile is not a problem,When I run ./configure >>> I make a new Makefile with the same data in it, hence what I just >>> modified is removed. >>> The issues I still have is the errors after that. Do you have any >>> idea what can be causing this errors? >>> >>> _______________________________________________________________________________ >>> >>> conftest.c: In function 'main': >>> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >>> function) >>> conftest.c:8: error: (Each undeclared identifier is reported only once >>> conftest.c:8: error: for each function it appears in.) >>> conftest.c:8: error: expected ')' before string constant >>> conftest.c:8: warning: format not a string literal and no format >>> arguments >>> ./configure: line 21462: ./conftest: No such file or directory >>> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >>> expected >>> configure: creating ./config.status >>> config.status: creating Makefile >>> config.status: creating config.h >>> config.status: config.h is unchanged >>> config.status: executing depfiles commands >>> ------------------------------------------------------------------------------- >>> >>> >>> >> >> This was corrected in CVS. I think you can just do the following in >> the top directory: >> >> cvs login: (pw is mousy) >> cvs update >> >> That will get the current fixes. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > apologies for the mix-up of your name. > I managed to get further on by updating CVS, the configure command gets > to the end without any errors, it still warns me that it is confused > about where to find the jni_md.h but I just edited the Makefile and > sorted that out. > I then run make, with no parameters following the instructions on the > Wiki, but that generated a few more errors: > ----------------------------------------------------------------------------------------------------------------------- > > gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. > -I/usr/lib/jvm/java-6-openjdk/include > /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE > -D_BSD_SOURCE -D__need_timespec -c > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o > /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' > undeclared (first use in this function) > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared > identifier is reported only once > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each > function it appears in.) > libtool: link: > `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a > valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 > ----------------------------------------------------------------------------------------------------------------------- > > Another question I have is, in which folder will the .so files be placed > after make finishes? > > thank you very much for your help. > Ah when you do cvs update pass the -Pd option cvs update -Pd Also, when you run configure, use --disable-PRINTER to only build the serial support. It will make things easier. --disable-LOCKFILES will also be easier to get going until you want to learn about how to prevent multiple applications from reading the same serial port. The link for debugging will describe where the files go. By default, it will install in the JRE/JDK under jre/lib/ext (the jar file) jre/lib/i386 (the .so file) Those are on the proper paths when you use the sun or ibm jdk. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sun May 3 01:30:43 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sun, 03 May 2009 08:30:43 +0100 Subject: [Rxtx] First use of RXTX package In-Reply-To: References: <49FCC5DA.6000700@ntlworld.com> Message-ID: <49FD4823.5080204@ntlworld.com> Ah > > when you do cvs update pass the -Pd option > > cvs update -Pd > > Also, when you run configure, use --disable-PRINTER to only build the > serial support. It will make things easier. --disable-LOCKFILES will > also be easier to get going until you want to learn about how to > prevent multiple applications from reading the same serial port. > > The link for debugging will describe where the files go. By default, > it will install in the JRE/JDK under > > jre/lib/ext (the jar file) > jre/lib/i386 (the .so file) > > Those are on the proper paths when you use the sun or ibm jdk. > > http://rxtx.qbang.org/wiki/index.php/Trouble_shooting > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, It as done it! I think this instructions you gave me should be on the Wiki, I can write them for you if you like. Also on the Wiki when you describe the three methods of installing the RxTx package it is confusing because as far as I can see, you always have to do method 1 or the .so files will not be generated(is this correct?). Then you can if you like change the location with method 1 & 2. Is it possible to modify the .la file to point to different directories for installation and then you can decide where to place the files? In a way I have learned quite a lot about Linux by having to struggle, with your help, to find solutions to the problems I encountered (I am still very new to Linux), but maybe we need to log these problems somewhere to make it less of a struggle for others like me. I have used the PortLister example to test it and it came up with my USB to dual Serial adaptor Ports. I will now explore the RxTx package, before I tackle the windows installation, I will let you know of my experience. Thank you for all your Help. Best Regards Luis From tjarvi at qbang.org Sun May 3 10:37:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 3 May 2009 10:37:50 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FD4823.5080204@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> <49FD4823.5080204@ntlworld.com> Message-ID: On Sun, 3 May 2009, Luis Moreira wrote: > Ah >> >> when you do cvs update pass the -Pd option >> >> cvs update -Pd >> >> Also, when you run configure, use --disable-PRINTER to only build the >> serial support. It will make things easier. --disable-LOCKFILES will >> also be easier to get going until you want to learn about how to >> prevent multiple applications from reading the same serial port. >> >> The link for debugging will describe where the files go. By default, >> it will install in the JRE/JDK under >> >> jre/lib/ext (the jar file) >> jre/lib/i386 (the .so file) >> >> Those are on the proper paths when you use the sun or ibm jdk. >> >> http://rxtx.qbang.org/wiki/index.php/Trouble_shooting >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > It as done it! > I think this instructions you gave me should be on the Wiki, I can write > them for you if you like. Also on the Wiki when you describe the three > methods of installing the RxTx package it is confusing because as far > as I can see, you always have to do method 1 or the .so files will not > be generated(is this correct?). Then you can if you like change the > location with method 1 & 2. Is it possible to modify the .la file to > point to different directories for installation and then you can decide > where to place the files? > In a way I have learned quite a lot about Linux by having to struggle, > with your help, to find solutions to the problems I encountered (I am > still very new to Linux), but maybe we need to log these problems > somewhere to make it less of a struggle for others like me. > > I have used the PortLister example to test it and it came up with my USB > to dual Serial adaptor Ports. > > I will now explore the RxTx package, before I tackle the windows > installation, I will let you know of my experience. > > Thank you for all your Help. > Hi Luis, The locations suggested for first time configuration could be documented in a new wiki page explaining that this is not the recommended general workflow but does help new users that are not worried about having rxtx installed into the JRE. For a professional environment, the user would want to follow the workflow currently on the wiki and keep their JRE clean. Often the user will not be able to add libraries to the JRE and will need to use their home directory or a sandbox. Feel free to add information to the wiki. I'd suggest creating comment in the current page and have the comment link to what worked for you as a first time user new to Linux. You can create a new page with your comments. In the long term, we will be working on an autoinstaller that works over the web. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Mon May 4 09:15:40 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Mon, 04 May 2009 16:15:40 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FF069C.8040406@ntlworld.com> Hi Trent, I have now installed the package on my 64 bit machine and when I run my program I get errors on the attachment. I know it as something to do with the architecture of my system but I can no figure out how to fix it. I have built it from source again, I did not transfer the files from machine to machine. can you please put me in the right direction. Thank you very much for your help. Best Regards Luis -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshoot.png Type: image/png Size: 25753 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090504/141ab5dc/attachment-0021.png From johnny.luong at trustcommerce.com Mon May 4 11:57:08 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 04 May 2009 10:57:08 -0700 Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FF069C.8040406@ntlworld.com> References: <49FF069C.8040406@ntlworld.com> Message-ID: <49FF2C74.90805@trustcommerce.com> Luis Moreira wrote: > Hi Trent, > I have now installed the package on my 64 bit machine and when I run my > program I get errors on the attachment. I know it as something to do > with the architecture of my system but I can no figure out how to fix > it. I have built it from source again, I did not transfer the files from > machine to machine. > can you please put me in the right direction. > Thank you very much for your help. > Best Regards > Luis > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Hi, Does running it on a 64-bit JVM help? Your host environment might be building objects for a 64-bit environment unless you did a cross-compile... -- you can find out by doing something like the following: johnny at spike:~$ java -version java version "1.6.0_0" OpenJDK Runtime Environment (build 1.6.0_0-b11) OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode) johnny at spike:~$ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) -Johnny From huangdongkai at gmail.com Wed May 6 11:06:06 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 01:06:06 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. Message-ID: Dear all, I recompile the rxtxSerial source code by MinGW32 and compile success. But when I run my Application which use rxtxSerial.dll to communicate with serial port, a runtime exception happened and application crash. I have no idea why it can not work, beacuse i have not change any source code of rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I have missed when compile the source code on Window NT? Here below is the output error massage. # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, tid=1360 # # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing windows-x86) # Problematic frame: # V [jvm.dll+0x1b6824] # # An error report file with more information is saved as: # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/32c1e699/attachment-0019.html From tjarvi at qbang.org Wed May 6 20:04:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 May 2009 20:04:10 -0600 (MDT) Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: On Thu, 7 May 2009, dongkai huang wrote: > Dear all, > ????? I recompile the rxtxSerial source code by MinGW32 and compile success. > But when I run my Application which use rxtxSerial.dll to communicate with > serial port, a runtime exception happened and application crash.? I have no > idea why it can not work, beacuse i have not change any source code of > rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I > have missed when compile the source code on Window NT? Here below is the > output error massage. > # > # An unexpected error has been detected by Java Runtime Environment: > # > #? EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, > tid=1360 > # > # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing > windows-x86) > > # Problematic frame: > # V? [jvm.dll+0x1b6824] > # > # An error report file with more information is saved as: > # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log > # > # If you would like to submit a bug report, please visit: > #?? http://java.sun.com/webapps/bugreport/crash.jsp > # > > > Hi Dongkai Could you explain how you compiled rxtx with mingw? Did you run configure? Was the compiler native or a cross compiler (like compiling on Linux for Windows)? Is the crash happening when you first open the port or is it happening randomly later on? -- Trent Jarvi tjarvi at qbang.org From huangdongkai at gmail.com Wed May 6 20:48:56 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 10:48:56 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Hi Trent, I was followed the step on INSTALL file, did not run the configure, I used the Makefile.mingw32 which include on the source code package, and only change some path( jdk home path etc.). And I use the native compiler on Windows. The crash happened on I call the getPortIdentifiers() every time. On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Dear all, >> I recompile the rxtxSerial source code by MinGW32 and compile >> success. >> But when I run my Application which use rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and application crash. I have >> no >> idea why it can not work, beacuse i have not change any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing >> I >> have missed when compile the source code on Window NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is saved as: >> # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> > Hi Dongkai > > Could you explain how you compiled rxtx with mingw? Did you run configure? > Was the compiler native or a cross compiler (like compiling on Linux for > Windows)? > > Is the crash happening when you first open the port or is it happening > randomly later on? > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/733eded5/attachment-0019.html From m.j.tandy at warwick.ac.uk Thu May 7 10:39:12 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 7 May 2009 17:39:12 +0100 Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. Message-ID: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> I've encountered a bug in how XON/XOFF are handled on Windows. The symptoms were: 1. XON/XOFF from device to PC did not stop transmission. 2. XON/XOFF characters were present in data read from serial port input stream, when it was expected that they would be stripped out. 3. Investigation with SysInternals PortMon revealed the following configuration when using rxtx: 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 while HyperTerminal, which did not have the same problems as me, produced the following: 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 In other words, the problem is that, in addition to being told to use XON/XOFF flow control, the computer has to explicitly be told which characters to use for 'XON' and 'XOFF'. This part of the configuration was being missed out. I got the latest rxtx source from CVS, and identified the problem as an omission in the 'init_termios' function of 'termios.c', which configures the unix/termios 'c_cc' (control characters) data structure - but omits to configure the VSTART and VSTOP control characters. Later, the termios c_cc data structure is translated (by termios_to_DCB) into a data structure named 'DCB', which is passed to the windows serial port configuration interface. By adding two lines defining the standard XON/XOFF characters to the function init_termios, the bug is fixed. A patch doing this is attached. Thanks, Michael Tandy -------------- next part -------------- A non-text attachment was scrubbed... Name: xon-xoff.diff Type: application/octet-stream Size: 667 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/159c0dcc/attachment-0018.obj From tjarvi at qbang.org Thu May 7 17:57:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 May 2009 17:57:28 -0600 (MDT) Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. In-Reply-To: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> References: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> Message-ID: On Thu, 7 May 2009, Michael Tandy wrote: > I've encountered a bug in how XON/XOFF are handled on Windows. > > The symptoms were: > 1. XON/XOFF from device to PC did not stop transmission. > 2. XON/XOFF characters were present in data read from serial port > input stream, when it was expected that they would be stripped out. > 3. Investigation with SysInternals PortMon revealed the following > configuration when using rxtx: > > 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 > BRK:0 EVT:a XON:0 XOFF:0 > > while HyperTerminal, which did not have the same problems as me, > produced the following: > > 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 > > In other words, the problem is that, in addition to being told to use > XON/XOFF flow control, the computer has to explicitly be told which > characters to use for 'XON' and 'XOFF'. This part of the configuration > was being missed out. > > I got the latest rxtx source from CVS, and identified the problem as > an omission in the 'init_termios' function of 'termios.c', which > configures the unix/termios 'c_cc' (control characters) data structure > - but omits to configure the VSTART and VSTOP control characters. > Later, the termios c_cc data structure is translated (by > termios_to_DCB) into a data structure named 'DCB', which is passed to > the windows serial port configuration interface. > > By adding two lines defining the standard XON/XOFF characters to the > function init_termios, the bug is fixed. A patch doing this is > attached. > Thanks Michael, Good timing. I plan on releasing rxtx-2.2 this coming Sunday. -- Trent Jarvi tjarvi at qbang.org From wjr at weru.ksu.edu Fri May 8 11:38:29 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Fri, 08 May 2009 12:38:29 -0500 Subject: [Rxtx] swing jfilechooser lockup Message-ID: <4A046E15.6010907@weru.ksu.edu> Hi, I wrote a small swing app to download images from an industrial camera. I used the two way serial sample code as a starting point. The app works fine EXCEPT for a call to jfilechooser. After I open the comm port and then try to change the output directory or log file, the jfilechooser winds up trying to unpark (note, parking is not something I'm really familiar with) and doesn't. If I try to change the file or directory before I start the comm port, it works. If I click on menu items that don't call jfilechooser, everything is OK. If I try closing the comm port and then try to create a jfilechooser, it locks up. There is obviously some sort of deadlock here because the awt thread starts waiting on something but it's not clear what. I haven't gone thru the rxtx code yet because it's not in the file structure that netbeans wants for debugging purposes. However, debugging code that I don't have a clear idea of what it is supposed to do is not my idea of a good time. Does anyone have any ideas on what is going on here? Thanks, wjr From Bob_Jacobsen at lbl.gov Fri May 8 14:48:25 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Fri, 8 May 2009 13:48:25 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A046E15.6010907@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> Message-ID: At 12:38 PM -0500 5/8/09, Bill Rust wrote: >Hi, > >I wrote a small swing app to download images from an industrial camera. >I used the two way serial sample code as a starting point. The app works >fine EXCEPT for a call to jfilechooser. After I open the comm port and >then try to change the output directory or log file, the jfilechooser >winds up trying to unpark (note, parking is not something I'm really >familiar with) and doesn't. If I try to change the file or directory >before I start the comm port, it works. If I click on menu items that >don't call jfilechooser, everything is OK. If I try closing the comm >port and then try to create a jfilechooser, it locks up. There is >obviously some sort of deadlock here because the awt thread starts >waiting on something but it's not clear what. I haven't gone thru the >rxtx code yet because it's not in the file structure that netbeans wants >for debugging purposes. However, debugging code that I don't have a >clear idea of what it is supposed to do is not my idea of a good time. What is the threading structure of your code? The various high-function Swing components, such as JFileChooser, are notorious for doing Really Bad Stuff when invoked from off the Swing thread. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From bschlining at gmail.com Fri May 8 15:08:50 2009 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 8 May 2009 14:08:50 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: Bob's probably right...take look at javax.swing.SwingUtilites for the workaround to get your swing stuff invoked on the EventDispatchThread (EDT). Some swing-methods do work when called outside of the EDT, but just to be safe, do your creation and swing calls on the EDT. It's really simple, here's an example of a synchronous call. // Here's how to run stuff on the EDT from a different thread SwingUtilities.invokeAndWait(new Runnable() { public void run() { JFileChooser fc; // create, setup, show your filechooser // Get the result from the filechooser } }); To do a asynchronous call use SwingUtilities.invokeLater > >I wrote a small swing app to download images from an industrial camera. > >I used the two way serial sample code as a starting point. The app works > >fine EXCEPT for a call to jfilechooser. After I open the comm port and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090508/c21c2127/attachment-0017.html From tod at todbot.com Fri May 8 16:27:12 2009 From: tod at todbot.com (Tod E. Kurt) Date: Fri, 8 May 2009 15:27:12 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> This is the exact technique I use to let the user choose which serial port to use on startup. Here's a method I've got in many of my sketches: void choosePort() { String portlist[] = Serial.list(); String port = null; javax.swing.SwingUtilities.invokeLater(new Runnable() { public void run() { try { String port = (String) javax.swing.JOptionPane.showInputDialog( null, "Select Serial Port", "MySuperSketch", javax.swing.JOptionPane.QUESTION_MESSAGE, null, portlist, null); if( port == null ) { javax.swing.JOptionPane.showMessageDialog(null, "No port chosen, goodbye"); System.exit(1); } serialPort = port; } catch (Exception e) { e.printStackTrace(); } } } ); } On May 8, 2009, at 2:08 p, Brian Schlining wrote: > Bob's probably right...take look at javax.swing.SwingUtilites for > the workaround to get your swing stuff invoked on the > EventDispatchThread (EDT). Some swing-methods do work when called > outside of the EDT, but just to be safe, do your creation and swing > calls on the EDT. It's really simple, here's an example of a > synchronous call. > > // Here's how to run stuff on the EDT from a different thread > SwingUtilities.invokeAndWait(new Runnable() { > public void run() { > JFileChooser fc; // create, setup, show your filechooser > // Get the result from the filechooser > } > }); > > To do a asynchronous call use SwingUtilities.invokeLater > > > >I wrote a small swing app to download images from an industrial > camera. > >I used the two way serial sample code as a starting point. The app > works > >fine EXCEPT for a call to jfilechooser. After I open the comm port > and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From huangdongkai at gmail.com Sat May 9 04:46:22 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Sat, 9 May 2009 18:46:22 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Dear Trent, After I intsall the ming32-cross compile to compile the rxtxSerial.dll and testing, i found the same problem still exist. I am not sure my compiler version is the same as your's. Could you tell me the way you can success compile rxtx-2.1-7r2 release source code? Thanks for you kindly help. On Fri, May 8, 2009 at 8:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Hi Trent, >> The attach is the Make file I use to compile the rxtx. >> >> On Thu, May 7, 2009 at 10:48 AM, dongkai huang >> wrote: >> Hi Trent, >> I was followed the step on INSTALL file, did not run the >> configure, I used the Makefile.mingw32 which include on the >> source code package, and only change some path( jdk home path >> etc.). And I use the native compiler on Windows. >> The crash happened on I call the getPortIdentifiers() >> every time. >> >> On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: >> >> >> On Thu, 7 May 2009, dongkai huang wrote: >> >> Dear all, >> I recompile the rxtxSerial source code by >> MinGW32 and compile success. >> But when I run my Application which use >> rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and >> application crash. I have no >> idea why it can not work, beacuse i have not change >> any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source >> code. Did some thing I >> have missed when compile the source code on Window >> NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java >> Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at >> pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 >> mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is >> saved as: >> # >> D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please >> visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> >> Hi Dongkai >> >> Could you explain how you compiled rxtx with mingw? Did you run >> configure? Was the compiler native or a cross compiler (like >> compiling on Linux for Windows)? >> >> Is the crash happening when you first open the port or is it >> happening randomly later on? >> >> > Thanks Dongkai > > I'll look at your Makefile tomorrow. Which version of mingw was this? > > I suspect there is a problem with that makefile. I usually built that > version of rxtx for windows with a mingw32 cross compiler using the > configure script. > > The configure script may well work for you if you have a cygwin environment > with mingw instead of gcc. I'll take a look at what is different. > > -- > > Trent Jarvi > tjarvi at qbang.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090509/b729c429/attachment-0017.html From wjr at weru.ksu.edu Wed May 13 15:50:30 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Wed, 13 May 2009 16:50:30 -0500 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> Message-ID: <4A0B40A6.5070204@weru.ksu.edu> Tod's solution misses the point. He is picking and opening the serial port. That's the step before where my problem occurs. To recap: 1. I have a simple java swing app. 2. On the menu bar, there is the standard set, file, etc., of jmenu's. Under file, there is a jmenuitem, logfileopen, which pops up a jfilechooser to select a logfile and another jmenuitem, setprefix, which pops up a jdialog to allow the user to type in a file name prefix for downloaded images. 3. There is another jmenuitem that starts the commport running. 4. When logfileopen is pressed before the commport is started, it works. 5. When logfileopen is pressed after the commport is started, it hangs. 6. setprefix works whether or not the commport is started. 7. portIdentifier.open starts a thread that goes into a native method, RXTXPort.eventLoop, and never returns. 8. java.sun bugs has a bug report, 6741890, that is similar but their workaround doesn't. 9. When it locks up, there is a swing-shell thread that appears to be down in some native libraries, winshellfolder2 10. The awt-eventQ thread is unblocked but in code that says its parked. If you have anymore ideas, I'd really appreciate them. wjr Tod E. Kurt wrote: > This is the exact technique I use to let the user choose which serial > port to use on startup. Here's a method I've got in many of my sketches: > > void choosePort() { > String portlist[] = Serial.list(); > String port = null; > javax.swing.SwingUtilities.invokeLater(new Runnable() { > public void run() { > try { > String port = (String) javax.swing.JOptionPane.showInputDialog( > null, > "Select Serial Port", > "MySuperSketch", > javax.swing.JOptionPane.QUESTION_MESSAGE, > null, portlist, null); > if( port == null ) { > javax.swing.JOptionPane.showMessageDialog(null, "No port > chosen, goodbye"); > System.exit(1); > } > serialPort = port; > } > catch (Exception e) { > e.printStackTrace(); > } > } > } ); > } > > > On May 8, 2009, at 2:08 p, Brian Schlining wrote: > >> Bob's probably right...take look at javax.swing.SwingUtilites for the >> workaround to get your swing stuff invoked on the EventDispatchThread >> (EDT). Some swing-methods do work when called outside of the EDT, but >> just to be safe, do your creation and swing calls on the EDT. It's >> really simple, here's an example of a synchronous call. >> >> // Here's how to run stuff on the EDT from a different thread >> SwingUtilities.invokeAndWait(new Runnable() { >> public void run() { >> JFileChooser fc; // create, setup, show your filechooser >> // Get the result from the filechooser >> } >> }); >> >> To do a asynchronous call use SwingUtilities.invokeLater >> >> >> >I wrote a small swing app to download images from an industrial camera. >> >I used the two way serial sample code as a starting point. The app works >> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >> >then try to change the output directory or log file, the jfilechooser >> >winds up trying to unpark (note, parking is not something I'm really >> >familiar with) and doesn't. >> What is the threading structure of your code? >> >> The various high-function Swing components, such as JFileChooser, are >> notorious for doing Really Bad Stuff when invoked from off the Swing >> thread. >> >> Bob >> -- >> Bob Jacobsen, UC Berkeley >> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >> JacobsenRG >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -- >> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >> Brian Schlining >> bschlining at gmail.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx From m.j.tandy at warwick.ac.uk Wed May 13 16:42:24 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 13 May 2009 23:42:24 +0100 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A0B40A6.5070204@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> <4A0B40A6.5070204@weru.ksu.edu> Message-ID: <302aa0340905131542i601ec3f1w3b0b5879c23f8eca@mail.gmail.com> Perhaps you could post your program, or an excerpt of it sufficient to demonstrate the problem you're having, for us to have a look at? 2009/5/13 Bill Rust : > Tod's solution misses the point. He is picking and opening the serial > port. That's the step before where my problem occurs. > > To recap: > > 1. I have a simple java swing app. > 2. On the menu bar, there is the standard set, file, etc., of jmenu's. > Under file, there is a jmenuitem, logfileopen, which pops up a > jfilechooser to select a logfile and another jmenuitem, setprefix, which > pops up a jdialog to allow the user to type in a file name prefix for > downloaded images. > 3. There is another jmenuitem that starts the commport running. > 4. When logfileopen is pressed before the commport is started, it works. > 5. When logfileopen is pressed after the commport is started, it hangs. > 6. setprefix works whether or not the commport is started. > 7. portIdentifier.open starts a thread that goes into a native > method, ? ? ? ? ? ? ? ? ? ? ? ? RXTXPort.eventLoop, and never returns. > 8. java.sun bugs has a bug report, 6741890, that is similar but > their ? ? ? ? ? ? ? ? ? workaround doesn't. > 9. When it locks up, there is a swing-shell thread that appears to be > ? ? ? ?down in some native libraries, winshellfolder2 > 10. The awt-eventQ thread is unblocked but in code that says its parked. > > If you have anymore ideas, I'd really appreciate them. > > wjr > > Tod E. Kurt wrote: >> This is the exact technique I use to let the user choose which serial >> port to use on startup. ?Here's a method I've got in many of my sketches: >> >> void choosePort() { >> ? String portlist[] = Serial.list(); >> ? String port = null; >> ? javax.swing.SwingUtilities.invokeLater(new Runnable() { >> ? ? public void run() { >> ? ? ? try { >> ? ? ? ? String port = (String) javax.swing.JOptionPane.showInputDialog( >> null, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Select Serial Port", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "MySuperSketch", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? javax.swing.JOptionPane.QUESTION_MESSAGE, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? null, portlist, null); >> ? ? ? ? if( port == null ) ?{ >> ? ? ? ? ? javax.swing.JOptionPane.showMessageDialog(null, "No port >> chosen, goodbye"); >> ? ? ? ? ? System.exit(1); >> ? ? ? ? } >> ? ? ? ? serialPort = port; >> ? ? ? } >> ? ? ? catch (Exception e) { >> ? ? ? ? e.printStackTrace(); >> ? ? ? } >> ? ? } >> ? } ); >> } >> >> >> On May 8, 2009, at 2:08 p, Brian Schlining wrote: >> >>> Bob's probably right...take look at javax.swing.SwingUtilites for the >>> workaround to get your swing stuff invoked on the EventDispatchThread >>> (EDT). Some swing-methods do work when called outside of the EDT, but >>> just to be safe, do your creation and swing calls on the EDT. It's >>> really simple, here's an example of a synchronous call. >>> >>> // Here's how to run stuff on the EDT from a different thread >>> SwingUtilities.invokeAndWait(new Runnable() { >>> ? ? ? public void run() { >>> ? ? ? ? ? ?JFileChooser fc; // create, setup, show your filechooser >>> ? ? ? ? ? ?// Get the result from the filechooser >>> ? ? ? } >>> }); >>> >>> To do a asynchronous call use SwingUtilities.invokeLater >>> >>> >>> >I wrote a small swing app to download images from an industrial camera. >>> >I used the two way serial sample code as a starting point. The app works >>> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >>> >then try to change the output directory or log file, the jfilechooser >>> >winds up trying to unpark (note, parking is not something I'm really >>> >familiar with) and doesn't. >>> What is the threading structure of your code? >>> >>> The various high-function Swing components, such as JFileChooser, are >>> notorious for doing Really Bad Stuff when invoked from off the Swing >>> thread. >>> >>> Bob >>> -- >>> Bob Jacobsen, UC Berkeley >>> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >>> JacobsenRG >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >>> -- >>> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >>> Brian Schlining >>> bschlining at gmail.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From m.j.tandy at warwick.ac.uk Thu May 14 03:05:36 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 14 May 2009 10:05:36 +0100 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A0B40A6.5070204@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> <4A0B40A6.5070204@weru.ksu.edu> Message-ID: <302aa0340905140205p6ceb5a9br24e00a50e9cafa5@mail.gmail.com> Java has a built in deadlock detection utility; run your program from the command line, then (on windows) press Ctrl+Break (On Linux, Ctrl+\ does the trick I'm told). That should produce status information and a stack trace for every running thread, including locks held and locks waited on. Maybe that would contain enough information for you to work out what's locking what? 2009/5/13 Bill Rust : > Tod's solution misses the point. He is picking and opening the serial > port. That's the step before where my problem occurs. > > To recap: > > 1. I have a simple java swing app. > 2. On the menu bar, there is the standard set, file, etc., of jmenu's. > Under file, there is a jmenuitem, logfileopen, which pops up a > jfilechooser to select a logfile and another jmenuitem, setprefix, which > pops up a jdialog to allow the user to type in a file name prefix for > downloaded images. > 3. There is another jmenuitem that starts the commport running. > 4. When logfileopen is pressed before the commport is started, it works. > 5. When logfileopen is pressed after the commport is started, it hangs. > 6. setprefix works whether or not the commport is started. > 7. portIdentifier.open starts a thread that goes into a native > method, ? ? ? ? ? ? ? ? ? ? ? ? RXTXPort.eventLoop, and never returns. > 8. java.sun bugs has a bug report, 6741890, that is similar but > their ? ? ? ? ? ? ? ? ? workaround doesn't. > 9. When it locks up, there is a swing-shell thread that appears to be > ? ? ? ?down in some native libraries, winshellfolder2 > 10. The awt-eventQ thread is unblocked but in code that says its parked. > > If you have anymore ideas, I'd really appreciate them. > > wjr > > Tod E. Kurt wrote: >> This is the exact technique I use to let the user choose which serial >> port to use on startup. ?Here's a method I've got in many of my sketches: >> >> void choosePort() { >> ? String portlist[] = Serial.list(); >> ? String port = null; >> ? javax.swing.SwingUtilities.invokeLater(new Runnable() { >> ? ? public void run() { >> ? ? ? try { >> ? ? ? ? String port = (String) javax.swing.JOptionPane.showInputDialog( >> null, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Select Serial Port", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "MySuperSketch", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? javax.swing.JOptionPane.QUESTION_MESSAGE, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? null, portlist, null); >> ? ? ? ? if( port == null ) ?{ >> ? ? ? ? ? javax.swing.JOptionPane.showMessageDialog(null, "No port >> chosen, goodbye"); >> ? ? ? ? ? System.exit(1); >> ? ? ? ? } >> ? ? ? ? serialPort = port; >> ? ? ? } >> ? ? ? catch (Exception e) { >> ? ? ? ? e.printStackTrace(); >> ? ? ? } >> ? ? } >> ? } ); >> } >> >> >> On May 8, 2009, at 2:08 p, Brian Schlining wrote: >> >>> Bob's probably right...take look at javax.swing.SwingUtilites for the >>> workaround to get your swing stuff invoked on the EventDispatchThread >>> (EDT). Some swing-methods do work when called outside of the EDT, but >>> just to be safe, do your creation and swing calls on the EDT. It's >>> really simple, here's an example of a synchronous call. >>> >>> // Here's how to run stuff on the EDT from a different thread >>> SwingUtilities.invokeAndWait(new Runnable() { >>> ? ? ? public void run() { >>> ? ? ? ? ? ?JFileChooser fc; // create, setup, show your filechooser >>> ? ? ? ? ? ?// Get the result from the filechooser >>> ? ? ? } >>> }); >>> >>> To do a asynchronous call use SwingUtilities.invokeLater >>> >>> >>> >I wrote a small swing app to download images from an industrial camera. >>> >I used the two way serial sample code as a starting point. The app works >>> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >>> >then try to change the output directory or log file, the jfilechooser >>> >winds up trying to unpark (note, parking is not something I'm really >>> >familiar with) and doesn't. >>> What is the threading structure of your code? >>> >>> The various high-function Swing components, such as JFileChooser, are >>> notorious for doing Really Bad Stuff when invoked from off the Swing >>> thread. >>> >>> Bob >>> -- >>> Bob Jacobsen, UC Berkeley >>> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >>> JacobsenRG >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >>> -- >>> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >>> Brian Schlining >>> bschlining at gmail.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From cowwoc at bbs.darktech.org Fri May 15 07:18:29 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 09:18:29 -0400 Subject: [Rxtx] InputStream timeouts Message-ID: <4A0D6BA5.8020209@bbs.darktech.org> Why does InputStream.read() return -1 on timeout instead of throwing InterruptedIOException which has existed specifically for this purpose since JDK 1.0? Sockets throw SocketTimeoutException which extends InterruptedIOException. I suspect that this logic confuses BufferedInputStream as well as end-users. Can we introduce this change along with the other timeout-related changes? Gili From Steffen.DETTMER at ingenico.com Fri May 15 07:36:19 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 15 May 2009 15:36:19 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0D6BA5.8020209@bbs.darktech.org> References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <20090515133619.GC17036@elberon.bln.de.ingenico.com> * cowwoc wrote on Fri, May 15, 2009 at 09:18 -0400: > Why does InputStream.read() return -1 on timeout shouldn't it block and only avialable() should care about timeouts? That is how I understand `This method blocks until input data is available' from: http://java.sun.com/j2se/1.5.0/docs/api/java/io/InputStream.html#read() public abstract int read() throws IOException Reads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. A subclass must provide an implementation of this method. Returns: the next byte of data, or -1 if the end of the stream is reached. Throws: IOException - if an I/O error occurs. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Fri May 15 08:22:19 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 15 May 2009 17:22:19 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: >From the javadoc for InputStream: "If no byte is available because the end of the stream has been reached, the value -1 is returned." Since character timeout is not an indication of EOF condition I guess one could argue that 0 should be returned in case of timeout. On the other hand one could also argue that since no data was available (if it timed out) the serial port input stream was at the end of stream (albeit possibly temporarily only). Further the javadoc seems to forbid the return value 0 for Inputstream.read(): " This method blocks until input data is available, the end of the stream is detected, or an exception is thrown." So it can return n >= 1 , -1 or throw an exception. InputStream.read(byte[]) can return 0 but for consistency the options with the other read methods the return value for timeout needs to be -1 or an exception. It goes against my grain to think that I get an exception when I've set up a timeout and I am thus expecting a timeout to happen sometimes. So it is not an exceptional case but expected situation in which case a special return value is philosophically speaking more appropriate. So I'm against changing this behavior. I expect a lot of code depend on the -1 or at least on not getting an exception when a timeout occurs. In any case if an exception were to be thrown it should *not* be InterruptedIOException. >From the javadoc for InterruptedIOException: "An InterruptedIOException is thrown to indicate that an input or output transfer has been terminated because the thread performing it was interrupted. The field bytesTransferred indicates how many bytes were successfully transferred before the interruption occurred" I do not think this matches the case for serial port receive character timeout. I read the javadoc above so that I get this exception when the thread in my code that is performing a read or write operation gets interrupted by Thread.interrupt(). And this is used to handle exactly that case: being able to gracefully and cleanly interrupt threads. my 2 snt worth br Kusti > From: cowwoc > Date: Fri, 15 May 2009 16:18:29 +0300 > To: rxtx > Conversation: [Rxtx] InputStream timeouts > Subject: [Rxtx] InputStream timeouts > > > > Why does InputStream.read() return -1 on timeout instead of > throwing InterruptedIOException which has existed specifically for this > purpose since JDK 1.0? Sockets throw SocketTimeoutException which > extends InterruptedIOException. I suspect that this logic confuses > BufferedInputStream as well as end-users. Can we introduce this change > along with the other timeout-related changes? > > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From cowwoc at bbs.darktech.org Fri May 15 08:35:27 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 10:35:27 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <4A0D7DAF.5030705@bbs.darktech.org> I disagree with your interpretation. Read SocketTimeoutException to see what I mean. InterruptedIOException means the operation was interrupted, not necessarily by way of Thread.interrupt(). Returning 0 in case of timeout sounds wrong to me because it is a legal byte value that could have been read. Returning -1 also sounds wrong to me because this isn't strictly the end of stream. BufferedInputStream and others assume that once you reach the end of stream you will never see more data, ever. As far as I know, the core APIs are written in terms of throwing InterruptedIOException for timeouts. Gili Kustaa Nyholm wrote: > >>From the javadoc for InputStream: > > "If no byte is available because the end of the stream has been reached, the > value -1 is returned." > > > Since character timeout is not an indication of EOF condition I guess one > could argue that 0 should be returned in case of timeout. On the other hand > one could also argue that since no data was available (if it timed out) the > serial port input stream was at the end of stream (albeit possibly > temporarily only). Further the javadoc seems to forbid the return value 0 > for Inputstream.read(): > > " This method blocks until input data is available, the end of the stream is > detected, or an exception is thrown." > > So it can return n >= 1 , -1 or throw an exception. InputStream.read(byte[]) > can return 0 but for consistency the options with the other read methods the > return value for timeout needs to be -1 or an exception. > > It goes against my grain to think that I get an exception when I've set up a > timeout and I am thus expecting a timeout to happen sometimes. So it is not > an exceptional case but expected situation in which case a special return > value is philosophically speaking more appropriate. > > So I'm against changing this behavior. I expect a lot of code depend on the > -1 or at least on not getting an exception when a timeout occurs. > > In any case if an exception were to be thrown it should *not* be > InterruptedIOException. > >>From the javadoc for InterruptedIOException: > > > "An InterruptedIOException is thrown to indicate that an input or output > transfer has been terminated because the thread performing it was > interrupted. The field bytesTransferred indicates how many bytes were > successfully transferred before the interruption occurred" > > I do not think this matches the case for serial port receive character > timeout. I read the javadoc above so that I get this exception when the > thread in my code that is performing a read or write operation gets > interrupted by Thread.interrupt(). And this is used to handle exactly that > case: being able to gracefully and cleanly interrupt threads. > > > > my 2 snt worth br Kusti > > > > >> From: cowwoc >> Date: Fri, 15 May 2009 16:18:29 +0300 >> To: rxtx >> Conversation: [Rxtx] InputStream timeouts >> Subject: [Rxtx] InputStream timeouts >> >> >> >> Why does InputStream.read() return -1 on timeout instead of >> throwing InterruptedIOException which has existed specifically for this >> purpose since JDK 1.0? Sockets throw SocketTimeoutException which >> extends InterruptedIOException. I suspect that this logic confuses >> BufferedInputStream as well as end-users. Can we introduce this change >> along with the other timeout-related changes? >> >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From m.j.tandy at warwick.ac.uk Fri May 15 09:17:36 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Fri, 15 May 2009 16:17:36 +0100 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <302aa0340905150817o39812d7y1b896004a2dcc2ab@mail.gmail.com> > I disagree with your interpretation. Read SocketTimeoutException to see > what I mean. InterruptedIOException means the operation was interrupted, > not necessarily by way of Thread.interrupt(). Strangely enough, the javadoc for InterruptedIOException says: "An InterruptedIOException is thrown to indicate that an input or output transfer has been terminated because the thread performing it was interrupted."[1] But the subclass SocketTimeoutException is used differently - here's an example from sun.net.httpserver.request: /** * block() only called when available==0 and buf is empty */ private synchronized void block () throws IOException { long currtime = server.getTime(); long maxtime = currtime + readTimeout; while (currtime < maxtime) { if (selector.select (readTimeout) == 1) { selector.selectedKeys().clear(); available (); return; } currtime = server.getTime(); } throw new SocketTimeoutException ("no data received"); } So it seems that SocketTimeoutExceptions get thrown not upon thread interruptions, but a certain time after a blocking read is started. [1] http://java.sun.com/javase/6/docs/api/java/io/InterruptedIOException.html From cowwoc at bbs.darktech.org Fri May 15 11:06:53 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 13:06:53 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0DA0F4.9050203@bbs.darktech.org> References: <4A0DA0F4.9050203@bbs.darktech.org> Message-ID: <4A0DA12D.2050303@bbs.darktech.org> Forgot to CC the list. Gili cowwoc wrote: > > "Thread was interrupted" does not necessarily mean > Thread.interrupt(). It just means that the operation (run by the thread) > was interrupted. If you read the beginning sentence for > InterruptedIOException it reads "Signals that an I/O operation has been > interrupted". This says nothing about the thread itself. Michael's > subsequent post about SocketTimeoutException reinforces that point. > > By the way, I think that in general you need to interpret the > Javadoc for core classes in a broader sense than it seems. Older Javadoc > (from version 1.0) used to mention implementation details that were not > necessarily important and limited the applicability of the classes. > Newer documentation tends to go out of its way to avoid mentioning such > implementation detail and I believe that's a good thing. When > InterruptedIOException was written, Thread.interrupt() was probably the > only way to interrupt I/O operations. Nowadays there are others. Sun has > generalized its meaning over time as evident by SocketTimeoutException. > At least, that's my interpretation :) > > Gili > > Kustaa Nyholm wrote: >>> I disagree with your interpretation. Read >>> SocketTimeoutException to >>> see >>> what I mean. InterruptedIOException means the operation was interrupted, >>> not necessarily by way of Thread.interrupt(). >> >> Well SocketTimeoutException javadoc only says, very briefly: >> >> "Signals that a timeout has occurred on a socket read or accept." >> >> So that is not too helpful. But since it is derived from >> InterruptedIOException my interpretation it that they have an 'is-a' >> relationship and InterruptedIOException needs to honor the contract of >> InterruptedIOException which says: >> >> "...because the thread performing it was interrupted." >> >> To me this very specifically talks about interrupting threads with >> Thread.interrupt() >> >> >>> Returning 0 in case of timeout sounds wrong to me because it >>> is a >>> legal >>> byte value that could have been read. >> Agreed, that's what I tried to say. 0 is a legal byte value for read() to >> return so that cannot be used. For read read(byte[]) which returns the >> number of bytes read 0 could be used but there again 0 can be returned >> if 0 >> byte[] size is 0. So there again 0 is not a good option. >> >>> Returning -1 also sounds wrong to >>> me because this isn't strictly the end of stream. >> Like I said, it isn't strictly the end of stream. But also does not >> forbid treating it as (temporary) end of stream. >> >>> BufferedInputStream >>> and others assume that once you reach the end of stream you will never >>> see more data, ever. >> Can you provide a reference for that. >> >>> As far as I know, the core APIs are written in >>> terms of throwing InterruptedIOException for timeouts. >> Would also like to see something to support that. >> >> >> The behavior of throwing an exception on timeout is also a little bit >> problematic, consider: >> >> byte buf[1000]; >> int n=ins.read(buf); >> // do something with the n bytes received >> >> What happens if a timeout occurs before we have received 1000 bytes? >> >> If an exception is thrown then the user of the read() needs to handle >> the bytes received in two places or else those last <1000 bytes are lost. >> A better solution would be to return the bytes received so far and throw >> the exception on the next call (if any). But the main point is that >> neither of these case obviously correct and neither is specified in the >> javadocs. Where as a lot of code that just handles the return value >> of read(byte[]) correctly works without any further ado. >> >> >> >> The main thing is that I think we should not break existing applications, >> which I expect are not handling InterruptedIOException but many of >> which may >> depend on getting back -1 in case of timeouts. >> >> It has been a while since I used the javax.javacomm but I seem to recall >> that it returned -1 and I think this is the defining standard. >> >> I expect most rxtx users are more interested in compatibility and >> stability >> than semantic niceties and improving the API. >> >> br Kusti >> >> >> > From johnny.luong at trustcommerce.com Fri May 15 13:16:15 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Fri, 15 May 2009 12:16:15 -0700 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0DA12D.2050303@bbs.darktech.org> References: <4A0DA0F4.9050203@bbs.darktech.org> <4A0DA12D.2050303@bbs.darktech.org> Message-ID: <4A0DBF7F.50808@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 cowwoc wrote: | Forgot to CC the list. | | Gili | | cowwoc wrote: |> "Thread was interrupted" does not necessarily mean |> Thread.interrupt(). It just means that the operation (run by the thread) |> was interrupted. If you read the beginning sentence for |> InterruptedIOException it reads "Signals that an I/O operation has been |> interrupted". This says nothing about the thread itself. Michael's |> subsequent post about SocketTimeoutException reinforces that point. |> |> By the way, I think that in general you need to interpret the |> Javadoc for core classes in a broader sense than it seems. Older Javadoc |> (from version 1.0) used to mention implementation details that were not |> necessarily important and limited the applicability of the classes. |> Newer documentation tends to go out of its way to avoid mentioning such |> implementation detail and I believe that's a good thing. When |> InterruptedIOException was written, Thread.interrupt() was probably the |> only way to interrupt I/O operations. Nowadays there are others. Sun has |> generalized its meaning over time as evident by SocketTimeoutException. |> At least, that's my interpretation :) |> |> Gili |> |> Kustaa Nyholm wrote: |>>> I disagree with your interpretation. Read |>>> SocketTimeoutException to |>>> see |>>> what I mean. InterruptedIOException means the operation was interrupted, |>>> not necessarily by way of Thread.interrupt(). |>> Well SocketTimeoutException javadoc only says, very briefly: |>> |>> "Signals that a timeout has occurred on a socket read or accept." |>> |>> So that is not too helpful. But since it is derived from |>> InterruptedIOException my interpretation it that they have an 'is-a' |>> relationship and InterruptedIOException needs to honor the contract of |>> InterruptedIOException which says: |>> |>> "...because the thread performing it was interrupted." |>> |>> To me this very specifically talks about interrupting threads with |>> Thread.interrupt() |>> |>> |>>> Returning 0 in case of timeout sounds wrong to me because it |>>> is a |>>> legal |>>> byte value that could have been read. |>> Agreed, that's what I tried to say. 0 is a legal byte value for read() to |>> return so that cannot be used. For read read(byte[]) which returns the |>> number of bytes read 0 could be used but there again 0 can be returned |>> if 0 |>> byte[] size is 0. So there again 0 is not a good option. |>> |>>> Returning -1 also sounds wrong to |>>> me because this isn't strictly the end of stream. |>> Like I said, it isn't strictly the end of stream. But also does not |>> forbid treating it as (temporary) end of stream. |>> |>>> BufferedInputStream |>>> and others assume that once you reach the end of stream you will never |>>> see more data, ever. |>> Can you provide a reference for that. |>> |>>> As far as I know, the core APIs are written in |>>> terms of throwing InterruptedIOException for timeouts. |>> Would also like to see something to support that. |>> |>> |>> The behavior of throwing an exception on timeout is also a little bit |>> problematic, consider: |>> |>> byte buf[1000]; |>> int n=ins.read(buf); |>> // do something with the n bytes received |>> |>> What happens if a timeout occurs before we have received 1000 bytes? |>> |>> If an exception is thrown then the user of the read() needs to handle |>> the bytes received in two places or else those last <1000 bytes are lost. |>> A better solution would be to return the bytes received so far and throw |>> the exception on the next call (if any). But the main point is that |>> neither of these case obviously correct and neither is specified in the |>> javadocs. Where as a lot of code that just handles the return value |>> of read(byte[]) correctly works without any further ado. |>> |>> |>> |>> The main thing is that I think we should not break existing applications, |>> which I expect are not handling InterruptedIOException but many of |>> which may |>> depend on getting back -1 in case of timeouts. |>> |>> It has been a while since I used the javax.javacomm but I seem to recall |>> that it returned -1 and I think this is the defining standard. |>> |>> I expect most rxtx users are more interested in compatibility and |>> stability |>> than semantic niceties and improving the API. |>> |>> br Kusti |>> |>> |>> | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi, Maybe a better approach (improving the API) would be to consider implementing a NIO interface atop the underlying serial communication... ~ if someone desires the existing behavior, then they use a facade that lies atop of the NIO and provide the same quirks associated with it. As I see it, the implementation overrides the general contract of the InputStream to provide for the timeout functionality and it would be somewhat troublesome to expect a user of that API to catch subclasses of IOException. Best, Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoNv38ACgkQnQTBLXttTeWZ+wCeO4CTrI5l+vLPrjHl8fBj7FOL Ft8AnjQ7bXnvMhOlwZdK5CYAuoQeQ9u0 =QAax -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon May 18 03:49:50 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 11:49:50 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <20090518094950.GG17036@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, May 15, 2009 at 17:22 +0300: > >From the javadoc for InputStream: > > Since character timeout is not an indication of EOF condition I > guess one could argue that 0 should be returned in case of > timeout. A blocking operation logically has no timeout. It is blocking. Forever, until EOF or an error. This IMHO renders usage of read() useless and read(byte[]) must be used (or no InputStream). > On the other hand one could also argue that since no data was > available (if it timed out) IMHO, read() must not time out. What would happen with a small simple console app that is relying that InputStream is implemented as required by specification? It cannot tell `no byte was received but this is not an error, please call me again' - and why should it? I think, if this is not suited, i.e. if the application may want a byte but also may not want a byte, no blocking function must be invoked, but a select must be called instead or, if no select-style function is avialable, polling must be used. This is the InputStream way (block or poll). For streams the `may or may not want a byte' may sound unlikely, but in practice this is what happens, for instance, if there is some CANCEL button in a GUI or so. Closing the stream often also is no option because it cannot be reopend but it might be needed again later. In classic unix apps often signals were used (read(2) can return EINTR), but in Java this isn't possible AFAIK. EINTR IMHO has not much relation to InterruptedIOException and I think InterruptedIOException cannot be `enforced' without doing harm. > It goes against my grain to think that I get an exception when > I've set up a timeout yeah, I thought the same and when I hit this InputStream the first time I though: ohh, a bug. Or a bunch of :-) As specified, InputStream has no timeout. If you set a timeout, then somewhere else (e.g. a sub class). In this case, the sub class should also offer a way to wait for this timeout (e.g. a select style function). In practice, this makes not much sense, leaving the options not to use it at all (but what else then?) or to violate the specification. Unfortunately it seems that subclasses add setTimeout but no select() or tryRead() or simply a available()-style with a timeout parameter. Then applications would simply use this subclasses. In practice, then it does not help that they derive InputStream at all, so personally I think they should not derive from it but instead define something with a meaning :-) But I think in practice, for read(byte[]) returning 0 (e.g. in case of [intercharacter] timeout) for many people seems straightforward - so this is probably what most people will expect. (an interesting question is how those bugs happend to the Java guys, because those topics are well known since ages and solved, for instance, in the BSD socket API, but probably they didn't know it. It took years but now it seems they understood and tried it again by some NIO which is more in the `usual way'. Next version might be usable - I wouldn't be surprised if this one then is BSD socket API alike :-) SCNR). So in practice I think: - don't use read() but read(byte[]) or read(byte[], int, int) - handle `0 bytes read' situation - polling avialable() in practice may often not be suited because avialable() has no timeout parameter and if response time is important, small polling intervals would be needed which generate load - try to avoid using InputStream (from applications) directly because it sucks and it is /not/ generic (implementations may interpret it differently because it MUST be interpreted because the specification makes not much sense in many cases) - IOException and InterruptedIOException are for I/O error situations. Additionally I think, InterruptedIOException.bytesTransferred cannot be reliable because there are cases where the OS cannot surely know this and thus cannot tell it the JVM also, peer may have not received them even if they were sent As far as I know this is exactly what rxtx is doing. When having many clients this require many threads and might be less performant, so best is not to have one thousand serial ports :-) Returning 0 here IMHO also is the only option that does not `directly' violate the spec. It tells `there is an attempt to read at least one byte.' so someone could argue that the dear computer `attempted but found no time to do so' :-) > So I'm against changing this behavior. I expect a lot of code > depend on the -1 or at least on not getting an exception when a > timeout occurs. Yes, I agree, -1 means End of file (or closed by peer) and exceptions are for errors. If exceptions should be added I think it could be made configurable. For instance by some Rs232InputStream.enableException(IOException e), store this exception and later if (e != null) throw e.clone() or so. > I do not think this matches the case for serial port receive character > timeout. I read the javadoc above so that I get this exception when the > thread in my code that is performing a read or write operation gets > interrupted by Thread.interrupt(). And this is used to handle exactly that > case: being able to gracefully and cleanly interrupt threads. (well, I think Thread.interrupt() also is a big topic on its own and I'm afraid there is no really reliable mechanism for `cleanly interrupt threads' and maybe even that logically threads cannot be interrupted cleanly at all) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From rxtx at qbang.org Mon May 18 05:17:08 2009 From: rxtx at qbang.org (VIAGRA ® Official Site) Date: Mon, 18 May 2009 05:17:08 -0600 Subject: [Rxtx] DISCOUNT ID42992 75% 0FF on Pfizer ! Message-ID: <200905181117.n4IBH8ku024296@rxtx.qbang.org> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/4c172d08/attachment-0008.html From Kustaa.Nyholm at planmeca.com Mon May 18 07:20:40 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 18 May 2009 16:20:40 +0300 Subject: [Rxtx] InputStream timeouts Message-ID: Oops, sorry sent this to Steffen directly instead of mailing list. So here for the list: > A blocking operation logically has no timeout. It is blocking. > Forever, until EOF or an error. This IMHO renders usage of read() > useless and read(byte[]) must be used (or no InputStream). This is true, however read(byte[]) too is blocking so logically that (allowing it to return with value 0 in case of timeout) is no better (or worse) than read(). According to InputsStream javadoc only when byte[].length is 0 is read(byte[]) non blocking and can return 0. But to be clear: I'm in favor of returning 0 in case of timeouts for read(byte[]) and -1 for read(). > >> On the other hand one could also argue that since no data was >> available (if it timed out) > > IMHO, read() must not time out. IMHO read() should behave consistently with respect to the other read(...) methods. If we allow them to timeout, we should also allow read() to timeout. And in that case we need a return value that separates that case from normal return value (0-255), so -1 seems like a good candidate. > What would happen with a small > simple console app that is relying that InputStream is > implemented as required by specification? It cannot tell `no byte > was received but this is not an error, please call me again' > - and why should it? I think that the simple console app would be just fine, because timeouts are disabled by default so the simple applications are not affected. > > In practice, this makes not much sense, leaving the options not > to use it at all (but what else then?) or to violate the > specification. The javadoc for CommPort.getInputStream() spells out the rules for timeouts: http://java.sun.com/products/javacomm/reference/api/javax/comm/CommPort.html #getInputStream() So, IMO, while it is interesting to discuss these things the javacomm specs is quite clear about blocking behavior and although there is some conflict between how (file) inputstream behaves and Commport inputstreams behave, I think rxtx should adhere to the javacomm spec. > But I think in practice, for read(byte[]) returning 0 (e.g. in > case of [intercharacter] timeout) for many people > seems straightforward - so this is probably what most people will > expect. Agreed, I'm 100% sure there are lots of people out there that use timeouts and depend on the current behavior. Changing this would not help them but infuriate them. > > (well, I think Thread.interrupt() also is a big topic on its own > and I'm afraid there is no really reliable mechanism for > `cleanly interrupt threads' and maybe even that logically > threads cannot be interrupted cleanly at all) Would be interesting to discuss that too but that is beyond the topic of this thread. However I still believe that the InterruptedIOException was introduced so that blocking IO calls could gracefully 'return' if the calling thread was interrupted. Weather this is reliable or clean or graceful could be discussed but to me it seem reasonable. If you have a thread that is blocking on some I/O we need a mechanism that allows stopping that thread in a controlled manner and InterruptedIOException seems to provide this. cheers Kusti From Steffen.DETTMER at ingenico.com Mon May 18 09:18:37 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 17:18:37 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <20090518151837.GS17036@elberon.bln.de.ingenico.com> [OT] * Kustaa Nyholm wrote on Mon, May 18, 2009 at 16:20 +0300: > > A blocking operation logically has no timeout. It is blocking. > > Forever, until EOF or an error. This IMHO renders usage of read() > > useless and read(byte[]) must be used (or no InputStream). > This is true, however read(byte[]) too is blocking so logically that > (allowing it to return with value 0 in case of timeout) is no better > (or worse) than read(). According to InputsStream javadoc only when > byte[].length is 0 is read(byte[]) non blocking and can return 0. I think the essential difference is that for read(byte[]) returning 0 is somewhat clear, but for read() 0 is a valid byte and thus it would be a horrible mess to also use it for timeouts :) > >> On the other hand one could also argue that since no data was > >> available (if it timed out) > > > > IMHO, read() must not time out. > > IMHO read() should behave consistently with respect to the > other read(...) methods. If we allow them to timeout, we should > also allow read() to timeout. And in that case we need a return > value that separates that case from normal return value (0-255), > so -1 seems like a good candidate. Well, but then this is not consistently to EOF handling... (and if read() cannot be consistent, maybe not using it at all is an option?) > > What would happen with a small simple console app that is > > relying that InputStream is implemented as required by > > specification? It cannot tell `no byte was received but this > > is not an error, please call me again' - and why should it? > I think that the simple console app would be just fine, because > timeouts are disabled by default so the simple applications are > not affected. Not setting timeouts IMHO does not mean no timeouts will be applied but that some default timeout is used instead, which could be infinite or some OS value, which in turn may be configurable (like the TCP wait timeouts). > > In practice, this makes not much sense, leaving the options not > > to use it at all (but what else then?) or to violate the > > specification. > > The javadoc for CommPort.getInputStream() spells out the rules for > timeouts: > > http://java.sun.com/products/javacomm/reference/api/javax/comm/CommPort.html > #getInputStream() > So, IMO, while it is interesting to discuss these things > the javacomm specs is quite clear about blocking behavior > and although there is some conflict between how (file) inputstream > behaves and Commport inputstreams behave, I think rxtx should > adhere to the javacomm spec. I think first this does not clearly state what happens a read caller when a timeout occures and second IMHO it does violate the InputStream specification contract (API/javadoc). Formally speaking, it is a bug :-) Also those `advisory methods' in a formal interface are bad, I think. But another topic and discussed already several times :) Yes, in the end it seems the clear correct possiblity (no timeouts) makes no sense, so something pragmatic is needed :-) > > But I think in practice, for read(byte[]) returning 0 (e.g. in > > case of [intercharacter] timeout) for many people > > seems straightforward - so this is probably what most people will > > expect. > Agreed, I'm 100% sure there are lots of people out there that > use timeouts and depend on the current behavior. Changing this > would not help them but infuriate them. yeah, and when shifting to another type of InputStream suddenly they may break, rendering that interface a bit useless, but this is all we have... Correct IMHO would be that the compiler is able to check whether an interface supports timeouts or not (i.e. all methods exist and work as specified or a different interface must be used. Lets say we would have InputStream and InputStreamTimeout or whatever, there would be so many possibilities, but most with own disadvantages). Well, I wonder why they did not even add a timeout parameter to available() and why they forgot about write timeouts completely (also there is no counterpart to available()). Anyway. > > (well, I think Thread.interrupt() also is a big topic on its own > > and I'm afraid there is no really reliable mechanism for > > `cleanly interrupt threads' and maybe even that logically > > threads cannot be interrupted cleanly at all) > Would be interesting to discuss that too but that is beyond the > topic of this thread. However I still believe that the > InterruptedIOException was introduced so that blocking > IO calls could gracefully 'return' if the calling thread > was interrupted. Yes, maybe they forgot it in first place, then found that read can throw IOExceptions only and thus invented InterruptedIOException for InterruptedException-alike cases? but anyway. > Weather this is reliable or clean or graceful could be > discussed but to me it seem reasonable. (With not reliable I mean, when for instance you wanted to write 10 byte and you get this exception telling 5 byte have been written, you cannot be sure what this means. Maybe the 6th byte is in a fifo or whatever. I think best is to avoid the need to handle this). > If you have a thread that is blocking on some I/O we need a > mechanism that allows stopping that thread in a controlled > manner and InterruptedIOException seems to provide this. I think also this is not reliable, because even if the JVM knows a thread is supposed to be `killed', I see at least two issues: first is that native code may be active and cannot be forced to return and second it could be that the thread would need to perform clean up tasks, and since Java does not support RAII (destructors cannot clean), at least you get in trouble when exceptions happening during this cleanup (i.e. exceptions after the thread stops). This in turn IMHO is likely to happen because a well-known situation to interrupt such a thread might be after some error, and after errors exceptions I think happen more often (because less well tested and others). Let's say the thread uses an InputStream (owned by someone else) and now discards it by calling it's close (which should be a delete - because what is an input stream which is closed? Obviously it is not an input stream anymore :-)). Now you might have a special InputStream requiring special things (it might be a protocol requiring some final quit message to be sent, it might need not to close it if used by someone else, too, additional actions may be needed). Logically this could be implemented (turing complete language :-)), but in practice it might not be possible, simply because too complex (to do it right in all circumstances). oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Mon May 18 10:02:39 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 18 May 2009 19:02:39 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: > Not setting timeouts IMHO does not mean no timeouts will be > applied but that some default timeout is used instead, which > could be infinite or some OS value, which in turn may be > configurable (like the TCP wait timeouts). > The javadoc says: "By default, receive timeout is not enabled." and "By default, receive threshold is not enabled." thus (from getInputStream javadoc): "block until any data is available" which is consistent InputStream contract. > I think first this does not clearly state what happens a read > caller when a timeout occures That is true. > and second IMHO it does violate the > InputStream specification contract (API/javadoc). Formally > speaking, it is a bug :-) Agreed, but I think given the advantages you get by using InputStream (as means of reading the serial port as opposed to coming up with some totally new Stream concept) I think this was reasonable compromise and bending of the rules. > yeah, and when shifting to another type of InputStream suddenly > they may break, rendering that interface a bit useless, but this > is all we have... Exactly. > (With not reliable I mean, when for instance you wanted to write > 10 byte and you get this exception telling 5 byte have been > written, you cannot be sure what this means. Maybe the 6th byte > is in a fifo or whatever. I think best is to avoid the need to > handle this). I think all we can assume is that at least 5 bytes have been written into the native driver, weather they are in the fifo or whatever we cannot know. But as you wrote, best avoid depending on this behaviour. > I think also this is not reliable, because even if the JVM knows > a thread is supposed to be `killed', I see at least two issues: > first is that native code may be active and cannot be forced to > return Yes, but this is sort of implementation detail, not an API or Java design issue. The JVM and system class implementations should guarantee this (I bet they don't, consistently, for all platforms and OSes). > and second it could be that the thread would need to > perform clean up tasks, and since Java does not support RAII > (destructors cannot clean), at least you get in trouble when > exceptions happening during this cleanup (i.e. exceptions after > the thread stops). I sort of see what you mean, but still I do not see how this could happen if the cleanup catches exceptions properly. But then I've not studied this in detail. > This in turn IMHO is likely to happen because > a well-known situation to interrupt such a thread might be after > some error, and after errors exceptions I think happen more often > (because less well tested and others). > > Let's say the thread uses an InputStream (owned by someone else) > and now discards it by calling it's close (which should be a > delete - because what is an input stream which is closed? > Obviously it is not an input stream anymore :-)). > Now you might have a special InputStream requiring special things > (it might be a protocol requiring some final quit message to be > sent, it might need not to close it if used by someone else, > too, additional actions may be needed). > Logically this could be implemented (turing complete language :-)), > but in practice it might not be possible, simply because too > complex (to do it right in all circumstances). Ok, I think I understand what you mean: you are saying that what mention aboce "if the cleanup catches exceptions properly" maybe be and often is too difficult/complex to implement and test properly? Yeah, seen that, been there, fallen for it... cheers Kusti From Steffen.DETTMER at ingenico.com Mon May 18 10:39:26 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 18:39:26 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: <20090518163925.GV17036@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Mon, May 18, 2009 at 19:02 +0300: > > Not setting timeouts IMHO does not mean no timeouts will be > > applied but that some default timeout is used instead, which > > could be infinite or some OS value, which in turn may be > > configurable (like the TCP wait timeouts). > > > The javadoc says: > "By default, receive timeout is not enabled." > and > "By default, receive threshold is not enabled." mmm... but they are optional, so what if a driver does not support timeouts but underlaying comm interface does? anyway, *I* would not rely (but loop) but maybe this is not needed. > > and second IMHO it does violate the > > InputStream specification contract (API/javadoc). Formally > > speaking, it is a bug :-) > Agreed, but I think given the advantages you get by using > InputStream (as means of reading the serial port as opposed > to coming up with some totally new Stream concept) I think > this was reasonable compromise and bending of the rules. I don't like InputStream at all. I think it is not an abstraction to remove and later re-add (hack in) needing things. I dislike that noone knows whether it streams bytes or chars or unicode or whatever. Also, I'm used birectional things (`all things are files') for communications, I think it is simpler. So InputStream IMHO is oversimplified. Maybe it was inspired by unix line discipline (but you can select it :-)). Who knows. Anyway. > > I think also this is not reliable, because even if the JVM knows > > a thread is supposed to be `killed', I see at least two issues: > > first is that native code may be active and cannot be forced to > > return > Yes, but this is sort of implementation detail, not an API or > Java design issue. The JVM and system class implementations should > guarantee this (I bet they don't, consistently, for all platforms > and OSes). I think when no reasonable implementation is possible, probably the design is not good. If there is no reasonable way to shutdown (kill) a thread (which is the case IMHO), it makes not much sense to design it. Instead, some mechanism would be needed. I guess the InterruptedException in fact is such a kind of mechanism. I'm not sure but I think Java itself disencourages to use it. > > and second it could be that the thread would need to > > perform clean up tasks, and since Java does not support RAII > > (destructors cannot clean), at least you get in trouble when > > exceptions happening during this cleanup (i.e. exceptions after > > the thread stops). > I sort of see what you mean, but still I do not see how this > could happen if the cleanup catches exceptions properly. But > then I've not studied this in detail. > Ok, I think I understand what you mean: you are saying that > what mention aboce "if the cleanup catches exceptions properly" > maybe be and often is too difficult/complex to implement and > test properly? Yes, since it should work for any implementation, it should work for InputStreams that call abitrary complex read operations. I have applications where the read leads to some CORBA calls to a remote C++ application which also has its complexity. Now in some finally {} exceptions can occure, for instance during member destruction (closing). For example, if you have a facade like implementation with: { old = setMyLogLevel(off); for (i=0; i Yeah, seen that, been there, fallen for it... (welcome in the club :-)) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bill7007 at gmail.com Mon May 18 11:08:45 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 18 May 2009 13:08:45 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090518151837.GS17036@elberon.bln.de.ingenico.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: I can add this thought, I think the timeout is part of a protocol, which should sit above RXTX. The main feature needed in RXTX to support a protocol using timeouts is a way to interrupt it into a known state, like a reset() function. The function should cause an exception to any associated thread that was waiting on IO, maybe a unique exception due to reset() call. An IO (as opposed to Interrupted) exception may be better since the reset() has to leave a known state which may affect IO in progress. I helped work a similar situation in a CAN bus protocol. In the protocol, a send would be followed by a wait for receive. A timeout thread was enabled which caused an "alarm" event to any registered handlers upon timeout. A receive canceled the timeout alarm. The timing and thread coordination is tricky but that is all left to the protocol code. The protocols timeout event handler reset the CAN controller to get it into a known state for a retry. The reset caused an IO exception to the waiting read thread which could check that a timeout had caused it. So, if timeout is considered part of a higher level protocol class, read and write don't need special interface features as long as there is a way for a waiting state in native code to be forced to exit in a reliable, detectable, manner. +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/c9b25045/attachment-0007.html From johnny.luong at trustcommerce.com Mon May 18 11:49:53 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 18 May 2009 10:49:53 -0700 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: <4A119FC1.3090700@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Johnson wrote: | I can add this thought, I think the timeout is part of a protocol, which | should sit above RXTX. The main feature needed in RXTX to support a protocol | using timeouts is a way to interrupt it into a known state, like a reset() | function. The function should cause an exception to any associated thread | that was waiting on IO, maybe a unique exception due to reset() call. An IO | (as opposed to Interrupted) exception may be better since the reset() has to | leave a known state which may affect IO in progress. | | I helped work a similar situation in a CAN bus protocol. In the protocol, a | send would be followed by a wait for receive. A timeout thread was enabled | which caused an "alarm" event to any registered handlers upon timeout. A | receive canceled the timeout alarm. The timing and thread coordination is | tricky but that is all left to the protocol code. The protocols timeout | event handler reset the CAN controller to get it into a known state for a | retry. The reset caused an IO exception to the waiting read thread which | could check that a timeout had caused it. | | So, if timeout is considered part of a higher level protocol class, read and | write don't need special interface features as long as there is a way for a | waiting state in native code to be forced to exit in a reliable, detectable, | manner. | | +BillJ | | | | ------------------------------------------------------------------------ | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx Hi Bill, This is all conjecture and probably a lot of work in practice, so its just a train of thought at this point (via NIO)... Supposer SerialPort were to implement a method that returned "SerialPortChannel" which worked along similar lines as a SocketChannel. ~ Then you could in practice, have a Selector object that did the timeout you described above (via a register method)... your read and write methods could block or not block and it would be a lot easier to drive multiple serial ports than what you have today. - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoRn8EACgkQnQTBLXttTeXm0gCfaua0ej3Rt0fogRR68bbEFG0Z BTwAn1s79U8ZU0yj6xcND8gyHzDmKKqq =ThWj -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon May 18 11:54:10 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 19:54:10 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: <20090518175409.GW17036@elberon.bln.de.ingenico.com> (OT) * Bill Johnson wrote on Mon, May 18, 2009 at 13:08 -0400: > I can add this thought, I think the timeout is part of a > protocol, which should sit above RXTX. Probably actually on both levels timeouts can be helpful; if there is some PPP/TCP or other full duplex multiplexing protcol I think at least it is nice to be able to read with some reasonable timeout(s). > I helped work a similar situation in a CAN bus protocol. In the > protocol, a send would be followed by a wait for receive. A > timeout thread was enabled which caused an "alarm" event to > any registered handlers upon timeout. A receive canceled the > timeout alarm. The timing and thread coordination is tricky but > that is all left to the protocol code. (this Bosch car protocol?) But if the protocol implementation knows the timeout value, wouldn't it be easier and suited better to have some way to apply it to the reads without needing multithreading? Was the implementation in Java? How to cancel the receive by the timeout alarm? Was it (protocol thread implementation) internally polling? You said later, `a way for a waiting state in native code to be forced to exit in a reliable, detectable, manner'. Sounds complicated :) Is this a generic requirement? I think, protocols often can be implemented to use InputStream (or some other interface) but also to offer the same interface (like the decorator pattern). At least when `stacking' such protocols it can become quite difficult, even if having an own thread per protocol instance. Of course heavily depends on the project and situation. Well, interesting topic :) > The protocols timeout event handler reset the CAN controller to > get it into a known state for a retry. The reset caused an IO > exception to the waiting read thread which could check that a > timeout had caused it. Ohh, the CAN controller must be reset? Though they would handle a whole frame automatically. I have no clue about this; surely it is very specific and complex. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bill7007 at gmail.com Mon May 18 12:25:19 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 18 May 2009 14:25:19 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A119FC1.3090700@trustcommerce.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <4A119FC1.3090700@trustcommerce.com> Message-ID: Hi Johnny, I think a SerialPortChannel could be a good example. It uses an underlying Socket which uses an underlying implementation to support open, timeouts, etc. As part of the implementation is where the current RXTX could come in, provided there is a way to back out of a blocking situation. +BillJ On Mon, May 18, 2009 at 1:49 PM, Johnny Luong < johnny.luong at trustcommerce.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Bill Johnson wrote: > | I can add this thought, I think the timeout is part of a protocol, which > | should sit above RXTX. > ... > > Hi Bill, > > This is all conjecture and probably a lot of work in practice, so its > just a train of thought at this point (via NIO)... > > Supposer SerialPort were to implement a method that returned > "SerialPortChannel" which worked along similar lines as a SocketChannel. > ~ Then you could in practice, have a Selector object that did the timeout > you described above (via a register method)... your read and write > methods could block or not block and it would be a lot easier to drive > multiple serial ports than what you have today. > > - -Johnny > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkoRn8EACgkQnQTBLXttTeXm0gCfaua0ej3Rt0fogRR68bbEFG0Z > BTwAn1s79U8ZU0yj6xcND8gyHzDmKKqq > =ThWj > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/0a44a920/attachment-0007.html From lyon at docjava.com Mon May 18 13:18:53 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 18 May 2009 15:18:53 -0400 Subject: [Rxtx] image capture In-Reply-To: References: Message-ID: Hi All, I know this is off-topic, but we have so many native method interface experts here, I just had to ask; Is anyone able to do image capture on a 64 bit mac, using Java? QT4J is not loadable using Java 6 (AFAIK). Thanks! - Doug From bill7007 at gmail.com Mon May 18 13:24:04 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 18 May 2009 15:24:04 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090518175409.GW17036@elberon.bln.de.ingenico.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> Message-ID: On Mon, May 18, 2009 at 1:54 PM, Steffen DETTMER < Steffen.DETTMER at ingenico.com> wrote: > (OT) > > * Bill Johnson wrote on Mon, May 18, 2009 at 13:08 -0400: > > I can add this thought, I think the timeout is part of a > > protocol, which should sit above RXTX. > > Probably actually on both levels timeouts can be helpful; if > there is some PPP/TCP or other full duplex multiplexing protcol I > think at least it is nice to be able to read with some reasonable > timeout(s). I think timeout at the native level does not fit well with a read() concept of timeout because it depends on the protocol not really on the read(). > > > I helped work a similar situation in a CAN bus protocol. In the > > protocol, a send would be followed by a wait for receive. A > > timeout thread was enabled which caused an "alarm" event to > > any registered handlers upon timeout. A receive canceled the > > timeout alarm. The timing and thread coordination is tricky but > > that is all left to the protocol code. > > (this Bosch car protocol?) > > But if the protocol implementation knows the timeout value, > wouldn't it be easier and suited better to have some way to apply > it to the reads without needing multithreading? > If you are waiting on a read and you are waiting on a timeout at the same time, that is two logical threads. Maybe you are looping check for one of two condition, character or timeout, but I think its the same logically as waiting for a character or a timeout exception. It is a special case where you try to read except if it take too long, sound a little like code? > Was the implementation in Java? How to cancel the receive by the > timeout alarm? Was it (protocol thread implementation) internally > polling? > The CAN bus was Java on a TINI embedded system for a warehouse system. It implemented a guaranteed delivery data path patterned after the Datagram interface, I called it a Cangram :-) The problem was how to cancel a read as part of a detected protocol or controller error. The hardware was reset via the native code driver which released resources so a restart was successful. I may have garbaged a thread and started a new one as part of it. > > You said later, `a way for a waiting state in native code to > be forced to exit in a reliable, detectable, manner'. Sounds > complicated :) Is this a generic requirement? I think, protocols > often can be implemented to use InputStream (or some other > interface) but also to offer the same interface (like the > decorator pattern). At least when `stacking' such protocols it > can become quite difficult, even if having an own thread per > protocol instance. Of course heavily depends on the project and > situation. Well, interesting topic :) > I think it (reset, stop, interrupt, whatever) should be a general requirement for any Java native interface code. Without it, your application can lock up and there is no reasonable way to regain control. > > The protocols timeout event handler reset the CAN controller to > > get it into a known state for a retry. The reset caused an IO > > exception to the waiting read thread which could check that a > > timeout had caused it. > > Ohh, the CAN controller must be reset? Though they would handle a > whole frame automatically. > I have no clue about this; surely it is very specific and complex. > The native interface resets it. In most cases, the only reason to reset it was so the native interface was freed up for a retry. If they had a interrupt() function, that may have been better. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. > This message may contain confidential and/or privileged information. If > you are not the addressee or authorized to receive this for the addressee, > you must not use, copy, disclose or take any action based on this message or > any information herein. If you have received this message in error, please > advise the sender immediately by reply e-mail and delete this message. Thank > you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/7df09a1e/attachment-0007.html From beat.arnet at gmail.com Mon May 18 13:27:07 2009 From: beat.arnet at gmail.com (Beat Arnet) Date: Mon, 18 May 2009 15:27:07 -0400 Subject: [Rxtx] Error 0x3e3 at termios.c(1301) Message-ID: All, I am experiencing a situation in which RXTX crashes consistently (both with 2.1 and 2.2). Steps to reproduce: - computer with JAVA program is sending bytes over RS-232 to embedded device, embedded device is off - embedded device powers up and transmit startup banner - JVM crashes: Error 0x3e3 at termios.c(1301) Any idea of what I should be looking for? Thanks! Beat # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6163696c, pid=808, tid=9648 # # Java VM: Java HotSpot(TM) Client VM (1.6.0-b105 mixed mode) # Problematic frame: # C 0x6163696c # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x0af7e400): JavaThread "Thread-4" [_thread_in_native, id=9648] siginfo: ExceptionCode=0xc0000005, reading address 0x6163696c Registers: EAX=0xffffffff, EBX=0x78652064, ECX=0x7c90f661, EDX=0x00000005 ESP=0x0c68f990, EBP=0x70706120, ESI=0x6f207469, EDI=0x6e612072 EIP=0x6163696c, EFLAGS=0x00010206 Top of Stack: (sp=0x0c68f990) 0x0c68f990: 6e6f6974 71657220 74736575 0a0a0d2e 0x0c68f9a0: 00000000 0c68f9d4 6d94556c 0daa3cb4 0x0c68f9b0: 74697277 74794265 3e0d2065 0a000a3e 0x0c68f9c0: 7c90cfea 7c80a059 000007d4 0af7e400 0x0c68f9d0: 6d909d8d 000007d4 00000002 6d945bf6 0x0c68f9e0: 0af7e400 00000001 00000000 0af8b024 0x0c68f9f0: 00000032 0af8b038 00000002 00000000 0x0c68fa00: 00000000 0af7e400 0af8b02c 06e85900 Instructions: (pc=0x6163696c) 0x6163695c: [error occurred during error reporting, step 100, id 0xc0000005] Stack: [0x0c640000,0x0c690000), sp=0x0c68f990, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C 0x6163696c [error occurred during error reporting, step 120, id 0xc0000005] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeByte(IZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write(I)V+86 j codeskin.serial.SerialPortRxtx2_1.write(I)V+29 j codeskin.c2oooprog.BootLoader2xxx$PingTask.run()V+87 v ~StubRoutines::call_stub -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/a692f306/attachment-0007.html From cowwoc at bbs.darktech.org Mon May 18 15:43:15 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Mon, 18 May 2009 17:43:15 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <4A119FC1.3090700@trustcommerce.com> Message-ID: <4A11D673.7080508@bbs.darktech.org> I'm in favor of using SerialPortChannel for timeouts and InputStream for non-blocking reads. This will allow us to follow the specification to the letter without any funky side-effects. In my view breaking the InputStream specification is a far greater sin than throwing InterruptedIOException from read(). Using SerialPortChannel and InputStream should allow us to please people in both camps without breaking the specification. Gili Bill Johnson wrote: > Hi Johnny, > > I think a SerialPortChannel could be a good example. It uses an > underlying Socket which uses an underlying implementation to support > open, timeouts, etc. As part of the implementation is where the current > RXTX could come in, provided there is a way to back out of a blocking > situation. > > +BillJ > > On Mon, May 18, 2009 at 1:49 PM, Johnny Luong > > > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Bill Johnson wrote: > | I can add this thought, I think the timeout is part of a protocol, > which > | should sit above RXTX. > > ... > > > Hi Bill, > > This is all conjecture and probably a lot of work in practice, so its > just a train of thought at this point (via NIO)... > > Supposer SerialPort were to implement a method that returned > "SerialPortChannel" which worked along similar lines as a SocketChannel. > ~ Then you could in practice, have a Selector object that did the > timeout > you described above (via a register method)... your read and write > methods could block or not block and it would be a lot easier to drive > multiple serial ports than what you have today. > > - -Johnny > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkoRn8EACgkQnQTBLXttTeXm0gCfaua0ej3Rt0fogRR68bbEFG0Z > BTwAn1s79U8ZU0yj6xcND8gyHzDmKKqq > =ThWj > -----END PGP SIGNATURE----- > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From bschlining at gmail.com Mon May 18 21:20:25 2009 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 18 May 2009 20:20:25 -0700 Subject: [Rxtx] Fwd: image capture In-Reply-To: References: Message-ID: forgot to cc the list ---------- Forwarded message ---------- From: Brian Schlining Date: Mon, May 18, 2009 at 20:19 Subject: Re: [Rxtx] image capture To: "Dr. Douglas Lyon" > Is anyone able to do image capture on a 64 bit mac, using > Java? Yes, I'm doing it from both video capture cards (Kona and Blackmagic) as well as from movie files. I'm only doing it on Java 5 (Mac) though. > QT4J is not loadable using Java 6 (AFAIK). Are you running this on a Mac or PC? Not that it matters I guess. QT4J is (unofficially) dead. It will be officially deprecated when Mac OS X 10.6 (Snow Leopard) is released, but for all practical purposes it's passed away. With each new release of QuickTime in the past year, I do the mad scramble to work around all the changes and bugs that are introduced. I'm working on once such 'fix' right now as a matter of fact. It's too bad too, QT4J was pretty darn powerful. Your best bet going forward is to rip out the QT4J code and replace it with a Mac/PC/Linux abstraction layer. On a Mac there you could try rococoa ( https://rococoa.dev.java.net) or just grab some QTKit samples off of Apples' developer site and write a JNI or JNA interface. On a PC, not sure what to tell you. I don't know what Apple's plans are with QT4J on a PC. They are pushing everyone away from QuickTime (C API) to QTKit (Cocoa/Objective-C). But on a PC ASFAIK there is no QTKit, so it's still QuickTime in the key of C. -- B ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/913800a4/attachment-0007.html From Kustaa.Nyholm at planmeca.com Tue May 19 00:26:27 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 19 May 2009 09:26:27 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A11D673.7080508@bbs.darktech.org> Message-ID: Oops, did it again, did not send this to the list, so we go: > > I'm in favor of using SerialPortChannel for timeouts and InputStream > for non-blocking reads. This will allow us to follow the specification > to the letter without any funky side-effects. > It was not clear to me what Gili is advocating here so I felt I needed to clarify this. > > In my view breaking the InputStream specification is a far greater sin > than throwing InterruptedIOException from read(). Throwing InterruptedIOException from InputStream.read() is just as big sin as it breaks the contract of InterruptedIOException , which says that the *thread* that was performing the IO was interrupted. Coneceptually I feel throwing an exception is a big sin in a situation which is not an error. A time out in a serial communication is almost always to be excepted since it is used to deal with real, live hardware outside the computer and very often it is a part of the higher level communication protocol, for example used to package or frame messages. Exceptions should be reserved for exceptional things not used for something that the programmer expects to happen normally. For one thing they incur an overhead. Granted, in a typical 9600 baud ie 1ms/char case the overhead is negligible, but it is there. On my 2.8 GHz Core 2 Duo try/throw/catch takes about 13 usec. In my view it is simply wrong to throw an exception for timeouts in a serial port. An even greater sin would be breaking existing code for design purity, at least in this case. > Using > SerialPortChannel and InputStream should allow us to please people in > both camps without breaking the specification. > So you are advocating adding a new class SerialPortChannel and a new method SerialPort.getSerialPortChannel() ? That would be acceptable in that it would not brake existing code but totally unnecessary in my view. I suspect most people turn to rxtx as a replacement for javacomm and are only interested in getting the job done. And the current API does this with very nicely. I think we all have better use for our time than to re-invent a serial port API. If the API bothers someone, I suggest they write a wrapper to implement the improvements and release it for interested users, if any. Would be kind of fun to see them struggle with all the API design issues and see what intellectual compromises they have to concede to. As a famous film ends in the sentence: "Nobody's perfect." cheers Kusti From Steffen.DETTMER at ingenico.com Tue May 19 02:12:14 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 19 May 2009 10:12:14 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A11D673.7080508@bbs.darktech.org> Message-ID: <20090519081214.GY17036@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Tue, May 19, 2009 at 09:26 +0300: > Coneceptually I feel throwing an exception is a big sin in a situation > which is not an error. Yes, I think the same. > In my view it is simply wrong to throw an exception for timeouts in > a serial port. Yes, I agree! > An even greater sin would be breaking existing code for design > purity, at least in this case. An even greater sin than that IMHO would be if the new stuff still isn't undoubtful powerful (which would IMHO need to include the possibility to select serial, TCP and other files simultaneously on systems that support it, e.g. for multi-serial-console applications or so). > So you are advocating adding a new class SerialPortChannel and > a new method SerialPort.getSerialPortChannel() ? SerialPortChannel would be a java.nio.channels.SelectableChannel or so? Or maybe a AbstractGatheringInterruptibleSelectableReadableWritableByteChannel. (the java name for `int fd' lol - SCNR). If changeing, I think an option could be to implement straightforward in native code offering its natural API (full timeout support, maybe as mandatory parameter, not dealing with Channel, Streams, source&sink, reactor&proactor patterns :-)). On top of that then both Channel and Stream and maybe something else for someone else. > That would be acceptable in that it would not brake existing code but > totally unnecessary in my view. I suspect most people turn to rxtx > as a replacement for javacomm and are only interested in getting the > job done. Yes, and most probably just have a few simultaneous connections. Others may need to have a dedicated, specialized and highly optimized JNI impl anyway (I guess). > If the API bothers someone, I suggest they write a wrapper to > implement the improvements and release it for interested users, > if any. Yes, actually that was what we did, but sometimes it was a bit cumbersome (because of InputStream and stuff). We implemented on top of that (instead of native interfaces or such) assuming that those interfaces won't change (but JNI interfaces probably are considered implementation details and thus probably will change). > Would be kind of fun to see them struggle with all the API > design issues and see what intellectual compromises they have > to concede to. Yeah, and then a nio successor comes and everone wanna go with it then :-) oki, Steffen ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Tue May 19 02:33:35 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 19 May 2009 10:33:35 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> Message-ID: <20090519083335.GZ17036@elberon.bln.de.ingenico.com> Hi! * Bill Johnson wrote on Mon, May 18, 2009 at 15:24 -0400: > * On Mon, May 18, 2009 at 1:54 PM, Steffen DETTMER wrote: > > * Bill Johnson wrote on Mon, May 18, 2009 at 13:08 -0400: > > > I can add this thought, I think the timeout is part of a > > > protocol, which should sit above RXTX. > > > > Probably actually on both levels timeouts can be helpful; if > > there is some PPP/TCP or other full duplex multiplexing > > protcol I think at least it is nice to be able to read with > > some reasonable timeout(s). > > I think timeout at the native level does not fit well with a > read() concept of timeout because it depends on the protocol > not really on the read(). What is special about `native level' to gain a special handling? I think all levels should support timeouts. Of course the read timeout an application invokes on a TCP stream has no direct relation to a PPP timeout and intercharacter timeouts on serial lines often depend on serial speed, CPU speed, required response timings, interrupt load etc, I think. So yes, I agree that protocols (often) define needed timeouts (to the lower layer) and the lower layer must offer support for timeouts. Is this what you mean with `depends on the protocol'? > > (this Bosch car protocol?) > > > > But if the protocol implementation knows the timeout value, > > wouldn't it be easier and suited better to have some way to apply > > it to the reads without needing multithreading? > > If you are waiting on a read and you are waiting on a timeout at the same > time, that is two logical threads. Ohh no, I disagree. I think, only if you have plenty of resources it is possible to waste a whole thread to watch a clock. When you have to read 100 connections of course you can use 100 threads, but better would be 1 thread with a select (or epoll or whatever), especially when assuming that the timeout is just a wait (thread sleep) time (when the OS is buffering the data anyway, which on Java running OSes probably is common). > Maybe you are looping check for one of two condition, character > or timeout, but I think its the same logically as waiting for a > character or a timeout exception. It is a special case where > you try to read except if it take too long, sound a little like > code? But isn't a maximum time a natural property of waiting? When you wait for someone for a meeting or so, you look to your watch from time to time and after half an hour or so you leave or continue your business. Select style IMHO is logically more event based than multi-threaded synchronous, but for applications or protocol implementations I found it comfortable when timeouts can be configured at any time. We even have two optional timeout parameters on our read function which eases implementing requirements like `receive both characters within 200 ms or reply with X'. > The CAN bus was Java on a TINI embedded system for a warehouse > system. It implemented a guaranteed delivery data path > patterned after the Datagram interface, I called it a Cangram > :-) The problem was how to cancel a read as part of a detected > protocol or controller error. The hardware was reset via the > native code driver which released resources so a restart was > successful. I may have garbaged a thread and started a new one > as part of it. cool :-) guess this was a very interesting project :) > I think it (reset, stop, interrupt, whatever) should be a > general requirement for any Java native interface code. Without > it, your application can lock up and there is no reasonable way > to regain control. alternatively, it could be required that any JNI function must return after some latest amount of time (i.e. specifying the maximum invocation time). I think, third-path-interruptions, maybe triggered from different threads, could quickly make code complicated because suddenly so many possible code paths can happen and they are hard to test (and cover). Personally, I think this is a major point against avoidable thread usage (even more if threads are not orthogonal) - hard to test, hard to ensure and prove it really is wrong always. Of course often enough it is needed anyway... oki, Steffen ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From michaeltandy at googlemail.com Tue May 19 08:33:09 2009 From: michaeltandy at googlemail.com (Michael Tandy) Date: Tue, 19 May 2009 15:33:09 +0100 Subject: [Rxtx] Rxtx native library loading Message-ID: <302aa0340905190733r4009e394v335b3ef47d84ffb5@mail.gmail.com> Attached is a patch which changes native library loading in Rxtx. Specifically, it makes two changes: 1. Looks in the directory RXTXcomm.jar is in for a native library, prior to searching java.library.path 2. Produces more informative error messages (in addition to the normal exceptions) if the native library cannot be found. The key benefits of this are: (a) to simplify setup; no need for administrator access to put things in shared/system directories, just unzip a file (containing my program as a .jar, RXTXcomm.jar, rxtxSerial.dll, librxtxSerial.so, and so on) and you're good to go; (b) If you've got multiple rxtx versions on your path (e.g. MATLAB puts its bin directory on your path, containing a copy of rxtxSerial.dll) you get the library file matching your jar file; (c) you don't need a big -Djava.library.path= every time you start your program; (d) if your native library file is missing, the error message is a bit more helpful (tells you where is being searched and for what); and (e) If the new code fails, it reverts to what the old code did, so it should be fully backwards-compatible. What do you think - is it worth including these changes in the main version of rxtx? Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: libraryloader.diff Type: text/x-diff Size: 10293 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090519/641c6573/attachment-0006.bin From bill7007 at gmail.com Tue May 19 12:37:32 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Tue, 19 May 2009 14:37:32 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090519083335.GZ17036@elberon.bln.de.ingenico.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> <20090519083335.GZ17036@elberon.bln.de.ingenico.com> Message-ID: On Tue, May 19, 2009 at 4:33 AM, Steffen DETTMER wrote: ... > > Is this what you mean with `depends on the protocol'? Native code is run time speed efficient, and that is important. I think I am saying, design wise, the function is read(). Timeout is a condition on read() only required by whatever comm protocol or comm logic you are using. I am thinking the whole purpose of SerialPort object is to represent a serial port so it should only contains methods and attributes of a serial port. A timeout is an event, part of the communication logic that is using that port. Wow, what a discussion. I had to go back and read it all to gather thoughts. I see multiple issues here. They coexist. 1) CommPort timeout implementation 2) Native blocking behavior and possible interruptions I think my protocol timeout thought was to state that the CommPort timeout may not be the best way implement a protocol timeout, but an alternative needs a blocking interrupt capability. Maybe that should be its own discussion. I do agree with the commandment, Thou shalt not modify the reference API. To focus back on Sun's CommPort interface, it does define a timeout that is optionally implemented and could be useful. I think a description of CommPort.getInputStream together with InputStream.read() leads to the implementation behavior: read() returns "the next byte of data, or -1 if the end of the stream is reached." So, end of stream must mean one of: 1) a timeout 2) "framing errors" (plural meaning parity and overrun too?) read(byte[]?b) returns "the total number of bytes read into the buffer, or -1 is there is no more data because the end of the stream has been reached." An end of stream here causes a return of the number read so far, or -1 if no data was yet read. How to determine cause of end of stream is a weakness of this API. Capturing a SerialPortEvent includes the framing error but not timeout. +BillJ From Steffen.DETTMER at ingenico.com Tue May 19 13:10:26 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 19 May 2009 21:10:26 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> <20090519083335.GZ17036@elberon.bln.de.ingenico.com> Message-ID: <20090519191025.GF17036@elberon.bln.de.ingenico.com> * Bill Johnson wrote on Tue, May 19, 2009 at 14:37 -0400: > methods and attributes of a serial port. A timeout is an event, part > of the communication logic that is using that port. (or the absence of data arrived events?) > read() returns "the next byte of data, or -1 if the end of the stream > is reached." > So, end of stream must mean one of: > 1) a timeout > 2) "framing errors" (plural meaning parity and overrun too?) I think neither timeout nor framing errors are end of stream (end of file) but only `remote DTR drop' is. I'm not sure (and always confuse) to which input line its maps and whether it is hi or lo active... I think, on linux, at least some versions, this worked well because when one side called close(fd) the other side read the EOF in exactly this moment. In general I think this is not reliable (different OSes surely handle it differently and it probably depends on several other things). With TCP sockets this can be expected to work (when one side shuts down its write channel, the other reads EOF after reading all data, which of course is returned first). Well, but probably some OS out there will be different just to annoy us :-) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From cowwoc at bbs.darktech.org Tue May 19 14:28:36 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 19 May 2009 16:28:36 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <4A131674.6000906@bbs.darktech.org> Guys, I am feeling very frustrated with this whole discussion. 1) There is no doubt that the current implementation breaks the InputStream API. A return value of -1 is already mapped to end-of-stream. For this reason, you *cannot* map the same value to a timeout. This is basic design-by-contract! 2) RXTX's implementation does not match javax.comm 100%. There are plenty of situations where the two implementations diverge. I am frustrated that people want to simultaneously freeze the APIs and fix issues that *cannot* be fixed purely in the implementation layer. 3) "Premature optimization is the root of all evil" and yet I see people complaining that exception handling costs 13 usec. Java places emphasizes correctness above performance. If you don't get that you shouldn't be coding in Java. More specific replies below... > Throwing InterruptedIOException from InputStream.read() is just as > big sin as it breaks the contract of InterruptedIOException , which > says that the *thread* that was performing the IO was interrupted. A thread getting interrupted is not the same as Thread.interrupt(). My interpretation is that interrupting the operation due to a timeout is a perfectly legal form of "thread interruption". Even with respect to Thread.interrupt(), you can't interrupt a thread, only the work it is executing. > Coneceptually I feel throwing an exception is a big sin in a situation > which is not an error. Exceptions refer to "exceptional circumstances" which is not the same as "errors". By that I mean that the "normally" the method returns 0-255, but exceptional cases such as timeouts are perfectly legal. > A time out in a serial communication is > almost always to be excepted since it is used to deal with real, live > hardware outside the computer I disagree. Some application-level protocols don't use timeouts at all. Why would your argument be true for serial connections but not sockets? > So you are advocating adding a new class SerialPortChannel and > a new method SerialPort.getSerialPortChannel() ? > > That would be acceptable in that it would not brake existing code but > totally unnecessary in my view. I suspect most people turn to rxtx > as a replacement for javacomm and are only interested in getting the > job done. And the current API does this with very nicely. I think > we all have better use for our time than to re-invent a serial port > API. The classic IO api is synchronous whereas NIO channels are asynchronous. Trying to retrofit timeouts on top of the old APIs will never be as clean as using NIO which is designed specifically for this purpose. Gili From tjarvi at qbang.org Tue May 19 17:19:15 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 May 2009 17:19:15 -0600 (MDT) Subject: [Rxtx] Rxtx native library loading In-Reply-To: <302aa0340905190733r4009e394v335b3ef47d84ffb5@mail.gmail.com> References: <302aa0340905190733r4009e394v335b3ef47d84ffb5@mail.gmail.com> Message-ID: On Tue, 19 May 2009, Michael Tandy wrote: > Attached is a patch which changes native library loading in Rxtx. > > Specifically, it makes two changes: > > 1. Looks in the directory RXTXcomm.jar is in for a native library, > prior to searching java.library.path > 2. Produces more informative error messages (in addition to the normal > exceptions) if the native library cannot be found. > > The key benefits of this are: > (a) to simplify setup; no need for administrator access to put things > in shared/system directories, just unzip a file (containing my program > as a .jar, RXTXcomm.jar, rxtxSerial.dll, librxtxSerial.so, and so on) > and you're good to go; > (b) If you've got multiple rxtx versions on your path (e.g. MATLAB > puts its bin directory on your path, containing a copy of > rxtxSerial.dll) you get the library file matching your jar file; > (c) you don't need a big -Djava.library.path= every time you start your program; > (d) if your native library file is missing, the error message is a bit > more helpful (tells you where is being searched and for what); > and (e) If the new code fails, it reverts to what the old code did, so > it should be fully backwards-compatible. > > What do you think - is it worth including these changes in the main > version of rxtx? > > Michael > Hi Michael, We will be putting a patch like yours in as soon as we release 2.2. The release was going to be mothers day but I got caught up :) I hope to do it next weekend. After that we will be looking at web installs which overlaps with your solution. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 19 17:44:25 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 May 2009 17:44:25 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A131674.6000906@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> Message-ID: On Tue, 19 May 2009, cowwoc wrote: >> A time out in a serial communication is >> almost always to be excepted since it is used to deal with real, live >> hardware outside the computer > > I disagree. Some application-level protocols don't use timeouts at all. > Why would your argument be true for serial connections but not sockets? > Hi Gili One fundamental difference between sockets, file io and RS232 communication is that sockets and file systems provide error handling. If a packet is lost, it is resent without the java API knowing about it. RS232 is actually an electrical signal standard. Serial communication exposes a UART without any meaningful error handling and cludgy error reporting. Given the above, ignoring timeouts is not really a valid rxtx level option. We could have a new option/method that allows you to get an InputStream or Channel that behaves as you wish. If we change the InputStream returned by getInputStream(), that would be change in the API (version 3.0) that forks our userbase. So I guess my question is whether or not you are trying to change the object returned by getInputStream or just looking for a means to get a different object you would like to define be returned. The later is far easier to accommodate. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 19 18:38:06 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 May 2009 18:38:06 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090519191025.GF17036@elberon.bln.de.ingenico.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> <20090519083335.GZ17036@elberon.bln.de.ingenico.com> <20090519191025.GF17036@elberon.bln.de.ingenico.com> Message-ID: On Tue, 19 May 2009, Steffen DETTMER wrote: > * Bill Johnson wrote on Tue, May 19, 2009 at 14:37 -0400: >> methods and attributes of a serial port. A timeout is an event, part >> of the communication logic that is using that port. > > (or the absence of data arrived events?) > >> read() returns "the next byte of data, or -1 if the end of the stream >> is reached." >> So, end of stream must mean one of: >> 1) a timeout >> 2) "framing errors" (plural meaning parity and overrun too?) > > I think neither timeout nor framing errors are end of stream (end > of file) but only `remote DTR drop' is. I'm not sure (and always > confuse) to which input line its maps and whether it is hi or lo > active... > There really is an end of input in termios that would match up fairly close in theory. The problem is it isnt really used as far as I know. termois.c_cc[VEOF] - the end of input character. I assume it is control-d. If you have a terminal open, try typing it into the shell prompt :) We even have some access to it in rxtx as extensions to commapi: private native byte nativeGetEndOfInputChar( ) throws UnsupportedCommOperationException; private native boolean nativeSetEndOfInputChar( byte b ) throws UnsupportedCommOperationException; GPIB has an entire wire dedicated to "EOI." -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue May 19 19:07:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 19 May 2009 21:07:34 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> Message-ID: <4A1357D6.9090705@bbs.darktech.org> Hi Trent, > RS232 is actually an electrical signal standard. Serial communication > exposes a UART without any meaningful error handling and cludgy error > reporting. > > Given the above, ignoring timeouts is not really a valid rxtx level > option. We could have a new option/method that allows you to get an > InputStream or Channel that behaves as you wish. Why? You could always use available() alongside blocking reads. > If we change the InputStream returned by getInputStream(), that would be > change in the API (version 3.0) that forks our userbase. > > So I guess my question is whether or not you are trying to change the > object returned by getInputStream or just looking for a means to get a > different object you would like to define be returned. > > The later is far easier to accommodate. I expect users to use getInputStream() for blocking reads and getInputChannel() for non-blocking reads. I understand your objections and normally I'd agree to wait for version 3.0 but RXTX's violation of the specification is a critical flaw in my opinion. Don't take my word for it... Take a look at this post I just ran across: http://stackoverflow.com/questions/611760/java-inputstream-read-blocking ------ quote ------- A read of -1 isn't doesn't mean, "there's no data present on this attempt," it means, "the stream is closed and there will never be any data so stop asking." If the end of the stream has not been reached, a read() call will block, just as the documentation specifies. [...] I've only used javax.comm for serial port I/O, and it implements InputStream as intended. It's possible that the rxtx implementation violates the contract of InputStream.read(), but if so, that's a very bad thing. Any code that was written to work with InputStream in general relies on the fact that -1 means EOF. Passing a broken java.io.InputStream to such code will cause problems. If rxtx supports non-blocking I/O, they should have created their own interface for reading, not extended InputStream. ------ quote ------- We learn two things from this post: 1) javax.comm respects the InputStream contract. It does not return -1 on timeouts. Seeing how you've written that any deviation from the javax.comm implementation is a bug I would suggest that this should be fixed immediately. 2) Violating the superclass specification can introduce an untold number of bugs. For example, I spent hours trying to figure out why BufferedReader.readLine() was returning null while the connection was still open. Gili From tjarvi at qbang.org Tue May 19 19:23:13 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 May 2009 19:23:13 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A1357D6.9090705@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> Message-ID: On Tue, 19 May 2009, cowwoc wrote: > > 1) javax.comm respects the InputStream contract. It does not return -1 on > timeouts. Seeing how you've written that any deviation from the javax.comm > implementation is a bug I would suggest that this should be fixed > immediately. > Hi Gili What is the observed behavior of javax.comm on timeout? Are you sure it didn't just disable timeouts by default? -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue May 19 19:37:24 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 19 May 2009 21:37:24 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> Message-ID: <4A135ED4.3090608@bbs.darktech.org> Trent Jarvi wrote: >> 1) javax.comm respects the InputStream contract. It does not return -1 >> on timeouts. Seeing how you've written that any deviation from the >> javax.comm implementation is a bug I would suggest that this should be >> fixed immediately. > What is the observed behavior of javax.comm on timeout? Are you sure it > didn't just disable timeouts by default? I'm not sure. Unfortunately, I've never gotten javax.comm to work under Windows and I don't have access to any other platform at this time. I assume that you've used javax.comm before, so I encourage you to try it on your end. Whatever they did, I really don't think that Sun would have violated the InputStream specification by returning -1 on timeout. As the BufferedReader.readLine() example shows, doing so triggers a lot of bugs. Gili From tjarvi at qbang.org Tue May 19 20:01:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 19 May 2009 20:01:53 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A135ED4.3090608@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> <4A135ED4.3090608@bbs.darktech.org> Message-ID: On Tue, 19 May 2009, cowwoc wrote: > Trent Jarvi wrote: >>> 1) javax.comm respects the InputStream contract. It does not return -1 on >>> timeouts. Seeing how you've written that any deviation from the javax.comm >>> implementation is a bug I would suggest that this should be fixed >>> immediately. > >> What is the observed behavior of javax.comm on timeout? Are you sure it >> didn't just disable timeouts by default? > > I'm not sure. Unfortunately, I've never gotten javax.comm to work > under Windows and I don't have access to any other platform at this time. I > assume that you've used javax.comm before, so I encourage you to try it on > your end. Whatever they did, I really don't think that Sun would have > violated the InputStream specification by returning -1 on timeout. As the > BufferedReader.readLine() example shows, doing so triggers a lot of bugs. > I've actually never used the Sun implementation. RXTX and CommAPI have very different origins that overlap with Kevin Hester's "JCL" patch to bring them together. The rest has been done from the docs. Default settings have always been a source of confusion which is why I ask. Disabled timeouts/thresholds would behave like you expect. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue May 19 20:30:22 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 19 May 2009 22:30:22 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> <4A135ED4.3090608@bbs.darktech.org> Message-ID: <4A136B3E.7010704@bbs.darktech.org> Trent Jarvi wrote: > What is the observed behavior of javax.comm on timeout? Are you sure > it didn't just disable timeouts by default? Can someone who has used javax.comm please investigate this and let us know? Thanks, Gili From Steffen.DETTMER at ingenico.com Wed May 20 02:30:08 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 20 May 2009 10:30:08 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A131674.6000906@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> Message-ID: <20090520083008.GH17036@elberon.bln.de.ingenico.com> * cowwoc wrote on Tue, May 19, 2009 at 16:28 -0400: > Guys, I am feeling very frustrated with this whole discussion. (Me too, but probably for different reason :-)) > 1) There is no doubt that the current implementation breaks the > InputStream API. (which must happen, because InputStream as defined is less usable) > A return value of -1 is already mapped to end-of-stream. For > this reason, you *cannot* map the same value to a timeout. This > is basic design-by-contract! Currently (actually we are still using RXTX-2.1-7 which surely isn't the latest version :)), in case of timeout read(byte[]) returns 0. We have a wrapper implementation (which because of some rxtx timeout precision issues) might be a few lines more than needed but provides timeout precision typical better than 100ms (for us, this is sufficient). I wrote about it here some years ago. So it's possible to work with rxtx even with InputStream. Not very comfortable thanks for InputStream, but it works. Java developers expect InputStream (with its limitations). I was told this several times. May the java and javax APIs suck or not, but it is what most java developers are used to use, expect and what we live with in so many other areas, too. > 2) RXTX's implementation does not match javax.comm 100%. There > are plenty of situations where the two implementations diverge. > I am frustrated that people want to simultaneously freeze the > APIs and fix issues that *cannot* be fixed purely in the > implementation layer. As already written, I think a `real complete exhaustive fix' isn't possible or desired here for various reasons. The current way works well and complies to java stuff as much as possible (the differences are enforced logically and the InputStream specification IMHO is simply wrong). Now why change, requiring people to redevelop their applications or wrappers? Why not alternatively publish one of those wrappers (yours? :-)) under a public license and/or add it to rxtx allowing people that want exceptions allowing them to use configurable exceptions (for example)? > 3) "Premature optimization is the root of all evil" and yet I > see people complaining that exception handling costs 13 usec. > Java places emphasizes correctness above performance. If you > don't get that you shouldn't be coding in Java. In general, also `oversimplification is a root of evil' and IMHO nice examples can be found in Java APIs, but this is the way `everyone' goes. Raping exceptions as return codes IMHO is not a performance problem but a design problem (in a non-RAII-aware language which is not allowing ensured resource cleanups by guaranteed destructors this is a real big problem, IMHO). I don't understand the discussion. We have a read returning number of bytes read. We have situations where no byte is read. Now the API doesn't tell that in this case zero should be returned, but I think this is so damn obvious, isn't it?? > > A time out in a serial communication is almost always to be > > excepted since it is used to deal with real, live hardware > > outside the computer > > I disagree. Some application-level protocols don't use timeouts > at all. Why would your argument be true for serial connections > but not sockets? In general, everything has (or should have) timeouts /or/ be under control of something. Technically, the latter may require use `timeouts in a loop' (some polling). TCP has timeouts, for instance retransmission timeouts. Situations were no timeouts are defined in TCP (was it e.g. FIN_WAIT?) in the past lead to issues. On real OSes there are also UDP sockets, UNIX Domain Sockets and whatever else - and all of them and serial ports can accessed via one and the same API and select'd at the same time: timeout supported is simply built-in. For complex protcols, like TCP, all the heaps of defined timeouts might not be as visible as for serial case, where typical applications handle details themself, but they exist. > The classic IO api is synchronous whereas NIO channels are > asynchronous. Trying to retrofit timeouts on top of the old > APIs will never be as clean as using NIO which is designed > specifically for this purpose. I think classic is BSD socket API, which IMHO looks like a natural evolution of classic unix APIs. Works also for serial and everything (at least on unix and cygwin). I think Java people didn't saw the big picture and tried to simplify but oversimplified, assuming, InputStream could be used for all types of communication. Actually, it even can, but not alone (usually, you additionally need OutputStream and some ioctl). Now of course it was nice and sexy to critise the non-type-safe ioctl and select and to drop it - but this of course is no solution. Just ignoring the difficulties rarely helps. NIO is a bit more BSD socket API style, a step into the direction where everything comes from. Next version might take another step and reach the goal. Who knows. As far as I know none of the issues that lead to NIO (mostly performance and scalability) apply to rxtx. The only thing that seems to appy is that some buggy Javadoc tells InputStream would be blocking, available has no timeout, write timeouts are also not supported - and read(byte[]) never returns 0. Which quickly, easily and straightforward `fixes' the issues. That is what rxtx did. Isn't this fine? oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From m.j.tandy at warwick.ac.uk Wed May 20 03:01:51 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 20 May 2009 10:01:51 +0100 Subject: [Rxtx] InputStream timeouts In-Reply-To: <302aa0340905200201r912d9d0m6c9e1e41e049f1df@mail.gmail.com> References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> <302aa0340905200201r912d9d0m6c9e1e41e049f1df@mail.gmail.com> Message-ID: <302aa0340905200201t13a31a4bq30f60042c50fde63@mail.gmail.com> > 2) Violating the superclass specification can introduce an untold number > of bugs. For example, I spent hours trying to figure out why > BufferedReader.readLine() was returning null while the connection was > still open. We're discussing what the read() method does on timeout - but isn't the failure of BufferedReader.readLine caused by read(byte[] b, int off, int len) returning '0 bytes read' - not caused by what the read() method does on timeout? I mean, when I run the code below (Java 1.6.0_13-b03 / Sun JDK 6) the output is: Attempting to read a line... program called inputstream's read(byte[] b, int off, int len) java.io.IOException: Underlying input stream returned zero bytes ? ? ? ?at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) ? ? ? ?at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) ? ? ? ?at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) ? ? ? ?at java.io.InputStreamReader.read(InputStreamReader.java:167) ? ? ? ?at java.io.BufferedReader.fill(BufferedReader.java:136) ? ? ? ?at java.io.BufferedReader.readLine(BufferedReader.java:299) ? ? ? ?at java.io.BufferedReader.readLine(BufferedReader.java:362) ? ? ? ?at inputstreamtest.Main.main(Main.java:14) And if I look at the source code for StreamDecoder.java [1] I see the following lines: ?283 ? ? ? ? ? ? ? int n = in.read(bb.array(), bb.arrayOffset() + pos, rem); ?284 ? ? ? ? ? ? ? if (n < 0) ?285 ? ? ? ? ? ? ? ? ? return n; ?286 ? ? ? ? ? ? ? if (n == 0) ?287 ? ? ? ? ? ? ? ? ? throw new IOException("Underlying input stream returned zero bytes"); Which kind of makes sense, because the javadoc for read(byte[] b, int off, int len) [2] does explicitly say that "If len is zero, then no bytes are read and 0 is returned; otherwise, there is an attempt to read at least one byte. If no byte is available because the stream is at end of file, the value -1 is returned; otherwise, at least one byte is read and stored into b." Is this the problem that you encountered? Michael [1] http://www.docjar.com/html/api/sun/nio/cs/StreamDecoder.java.html [2] http://java.sun.com/javase/6/docs/api/java/io/InputStream.html#read(byte[],%20int,%20int) // CODE BEGINS HERE package inputstreamtest; import java.io.BufferedReader; import java.io.IOException; import java.io.InputStream; import java.io.InputStreamReader; public class Main { ? ?public static void main(String[] args) { ? ? ? ?BufferedReader in = new BufferedReader(new InputStreamReader(new FakeInputStream())); ? ? ? ?System.out.println("Attempting to read a line..."); ? ? ? ?try { ? ? ? ? ? ?in.readLine(); ? ? ? ?} catch (IOException e) { ? ? ? ? ? ?e.printStackTrace(); ? ? ? ?} ? ?} ? ?private static class FakeInputStream extends InputStream { ? ? ? ?@Override ? ? ? ?public int read(byte[] b, int off, int len) { ? ? ? ? ? ?System.out.println("program called inputstream's read(byte[] b, int off, int len)"); ? ? ? ? ? ?return 0; ? ? ? ?} ? ? ? ?@Override ? ? ? ?public int read() throws IOException { ? ? ? ? ? ?System.out.println("program called inputstream's read()"); ? ? ? ? ? ?return -1; ? ? ? ?} ? ?} } From Steffen.DETTMER at ingenico.com Wed May 20 03:16:20 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 20 May 2009 11:16:20 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> <20090519083335.GZ17036@elberon.bln.de.ingenico.com> <20090519191025.GF17036@elberon.bln.de.ingenico.com> Message-ID: <20090520091620.GI17036@elberon.bln.de.ingenico.com> * Trent Jarvi wrote on Tue, May 19, 2009 at 18:38 -0600: > >I think neither timeout nor framing errors are end of stream (end > >of file) but only `remote DTR drop' is. I'm not sure (and always > >confuse) to which input line its maps and whether it is hi or lo > >active... > > There really is an end of input in termios that would match up > fairly close in theory. The problem is it isnt really used as > far as I know. > > termois.c_cc[VEOF] - the end of input character. I assume it > is control-d. If you have a terminal open, try typing it into > the shell prompt :) Ahh yes, this way it was! (what means `logged out' and why my modem has no carrier?! :)) With a null modem cable and a C++ implementation I tried it and found that you are right, it is working with ^D (but not with DTR as I claimed), thanks for the correction. In `stty raw' ^D is 0x04 but after `stty sane' ^D works as end of input character, as you said. select(2) tells ready for read and read(2) return 0 bytes, which means EOF :-) (Well, in strict pure theory I think this could be considered a property of the terminal line discipline canonical mode, which IMHO could be considered a protocol property) BTW, is someone using this EOF in general? Our C++ implementation supports both it seems it (EOF detection) was never used. I guess it depends on the domain someone is working in? I could imagine that some micro controller control interfaces use that? oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed May 20 03:32:00 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 20 May 2009 11:32:00 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> <20090518175409.GW17036@elberon.bln.de.ingenico.com> <20090519083335.GZ17036@elberon.bln.de.ingenico.com> <20090519191025.GF17036@elberon.bln.de.ingenico.com> Message-ID: <20090520093200.GK17036@elberon.bln.de.ingenico.com> ps. our java implementation using RXTX-2.1-7 (surely very old) does not detect the ^D in `stty sane' mode. also, just BTW, about the IOException interruption discussion. When I aborted the java command line test program by ^C, I got IOException: java.io.IOException: Interrupted system call in readArray which IMHO shows that Kusti is right. The code not detecting EOF is similar to: port_.enableReceiveTimeout(intTimeout); bytesRead = port_.getInputStream().read( buffer, totalBytesRead, bytesRequested ); switch (bytesRead) { case -1: readClosedByPeer_ = true; break; case 0: // log interchar timeout if (totalBytesRead > 0) { rs232Logger_.finest( "Intercharacter timeout (" + getByteReadTimeout() + " ms) while reading, might be Ok. Returning " + totalBytesRead + " bytes read so far" ); } if (!ENABLE_RECEIVE_TIMEOUT_PRECISION_LOGGING) { break; } So actually I don't know if readClosedByPeer ever worked (we don't use it anyway I think). oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Wed May 20 03:57:30 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 12:57:30 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <302aa0340905200201t13a31a4bq30f60042c50fde63@mail.gmail.com> Message-ID: > From: Michael Tandy > And if I look at the source code for StreamDecoder.java [1] I see the > following lines: > ?283 ? ? ? ? ? ? ? int n = in.read(bb.array(), bb.arrayOffset() + pos, rem); > ?284 ? ? ? ? ? ? ? if (n < 0) > ?285 ? ? ? ? ? ? ? ? ? return n; > ?286 ? ? ? ? ? ? ? if (n == 0) > ?287 ? ? ? ? ? ? ? ? ? throw new IOException("Underlying input stream > returned zero bytes"); > > Which kind of makes sense, because the javadoc for read(byte[] b, int > off, int len) [2] does explicitly say that "If len is zero, then no > bytes are read and 0 is returned; otherwise, there is an attempt to > read at least one byte. If no byte is available because the stream is > at end of file, the value -1 is returned; otherwise, at least one byte > is read and stored into b." Not realy relevant for the discussion but out of curiosity I had peek at the code you quoted and just a few lines above we see: 278 int lim = bb.limit(); 279 int pos = bb.position(); 280 assert (pos <= lim); 281 int rem = (pos <= lim ? lim - pos : 0); 282 assert rem > 0; If asserts are disabled (the default IIRC) then 'rem' could be 0 in which case throwing exception on line 287 is not correct in that it is legal for read(byte[]) to return under that circumstance. Of course it maybe that the design of StreamDecoder otherwise guarantees that lim > pos but this just shows how difficult it is to be logically consistent all the time. Further browsing the StreamDecoder and CharsetDecorder classes it seems, at least superficially, that nothing has been gained by checking and throwing an exception, the rest of code would have worked correctly even if the the read on line 283 would return 0. All code that I've ever written have handled read(byte[]) returning 0 correctly (touch wood!) taking it on it's stride. Why not, you need to prepare for read to return less than what you asked so it naturally falls to handle the case of 0 also. From Kustaa.Nyholm at planmeca.com Wed May 20 04:06:12 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 13:06:12 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090520083008.GH17036@elberon.bln.de.ingenico.com> Message-ID: > From: Steffen DETTMER > >> 1) There is no doubt that the current implementation breaks the >> InputStream API. > (which must happen, because InputStream as defined is less usable) > Exactly. > Now why change, requiring people to redevelop their applications > or wrappers? Why not alternatively publish one of those wrappers > (yours? :-)) under a public license and/or add it to rxtx > allowing people that want exceptions allowing them to use > configurable exceptions (for example)? > Hear,hear, agree whole heartedly! > > I don't understand the discussion. We have a read returning > number of bytes read. We have situations where no byte is read. > Now the API doesn't tell that in this case zero should be > returned, but I think this is so damn obvious, isn't it?? To me it is soooooo obvious. > > The only thing that seems to appy is that some buggy Javadoc > tells InputStream would be blocking, available has no timeout, > write timeouts are also not supported - and read(byte[]) never > returns 0. Which quickly, easily and straightforward `fixes' the > issues. That is what rxtx did. Isn't this fine? It is fine. It ain't broken, don't fix it. This is mainly a documentation issue. When the map and scenery disagree trust the scenery. Thanks Steffen for summing it up so nicely! cheers Kusti From cowwoc at bbs.darktech.org Wed May 20 04:39:31 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 06:39:31 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090520083008.GH17036@elberon.bln.de.ingenico.com> References: <4A131674.6000906@bbs.darktech.org> <20090520083008.GH17036@elberon.bln.de.ingenico.com> Message-ID: <4A13DDE3.8070703@bbs.darktech.org> Steffen DETTMER wrote: > * cowwoc wrote on Tue, May 19, 2009 at 16:28 -0400: >> Guys, I am feeling very frustrated with this whole discussion. > > (Me too, but probably for different reason :-)) > >> 1) There is no doubt that the current implementation breaks the >> InputStream API. > > (which must happen, because InputStream as defined is less usable) Not true. Either we follow the InputSteam specification or we define our own interface. Breaking the specification in this way will trigger unpredictable bugs. > Currently (actually we are still using RXTX-2.1-7 which surely > isn't the latest version :)), in case of timeout read(byte[]) > returns 0. > > I don't understand the discussion. We have a read returning > number of bytes read. We have situations where no byte is read. > Now the API doesn't tell that in this case zero should be > returned, but I think this is so damn obvious, isn't it?? Actually, the Javadoc for read(byte[]) says that at least one byte must be read: "If the length of b is zero, then no bytes are read and 0 is returned; otherwise, there is an attempt to read at least one byte. If no byte is available because the stream is at the end of the file, the value -1 is returned; otherwise, at least one byte is read and stored into b." > In general, everything has (or should have) timeouts /or/ be > under control of something. Technically, the latter may > require use `timeouts in a loop' (some polling). TCP has > timeouts, for instance retransmission timeouts. Situations were > no timeouts are defined in TCP (was it e.g. FIN_WAIT?) in the > past lead to issues. On real OSes there are also UDP sockets, > UNIX Domain Sockets and whatever else - and all of them and > serial ports can accessed via one and the same API and select'd > at the same time: timeout supported is simply built-in. > For complex protcols, like TCP, all the heaps of defined timeouts > might not be as visible as for serial case, where typical > applications handle details themself, but they exist. Fair enough, but "timeouts in a loop" -- using available() -- don't break the InputStream specification. > NIO is a bit more BSD socket API style, a step into the direction > where everything comes from. Next version might take another step > and reach the goal. Who knows. As far as I know none of the > issues that lead to NIO (mostly performance and scalability) > apply to rxtx. NIO allows you to select() on a channel with a timeout, which is the point of contention. > The only thing that seems to appy is that some buggy Javadoc > tells InputStream would be blocking, available has no timeout, > write timeouts are also not supported - and read(byte[]) never > returns 0. Which quickly, easily and straightforward `fixes' the > issues. That is what rxtx did. Isn't this fine? I'm not sure I understand. I get that you dislike that InputStream doesn't provide facilities for non-blocking reads but that is just life. You're supposed to either create your own interface or use NIO for that. In my view, breaking the superclass contract is always worse than inconveniencing yourself. Gili From cowwoc at bbs.darktech.org Wed May 20 04:41:14 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 06:41:14 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <302aa0340905200201t13a31a4bq30f60042c50fde63@mail.gmail.com> References: <4A131674.6000906@bbs.darktech.org> <4A1357D6.9090705@bbs.darktech.org> <302aa0340905200201r912d9d0m6c9e1e41e049f1df@mail.gmail.com> <302aa0340905200201t13a31a4bq30f60042c50fde63@mail.gmail.com> Message-ID: <4A13DE4A.70704@bbs.darktech.org> Yes. Gili Michael Tandy wrote: >> 2) Violating the superclass specification can introduce an untold number >> of bugs. For example, I spent hours trying to figure out why >> BufferedReader.readLine() was returning null while the connection was >> still open. > > We're discussing what the read() method does on timeout - but isn't > the failure of BufferedReader.readLine caused by read(byte[] b, int > off, int len) returning '0 bytes read' - not caused by what the read() > method does on timeout? > > I mean, when I run the code below (Java 1.6.0_13-b03 / Sun JDK 6) the output is: > > Attempting to read a line... > program called inputstream's read(byte[] b, int off, int len) > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > at inputstreamtest.Main.main(Main.java:14) > > And if I look at the source code for StreamDecoder.java [1] I see the > following lines: > 283 int n = in.read(bb.array(), bb.arrayOffset() + pos, rem); > 284 if (n < 0) > 285 return n; > 286 if (n == 0) > 287 throw new IOException("Underlying input stream > returned zero bytes"); > > Which kind of makes sense, because the javadoc for read(byte[] b, int > off, int len) [2] does explicitly say that "If len is zero, then no > bytes are read and 0 is returned; otherwise, there is an attempt to > read at least one byte. If no byte is available because the stream is > at end of file, the value -1 is returned; otherwise, at least one byte > is read and stored into b." > > Is this the problem that you encountered? > > Michael > > [1] http://www.docjar.com/html/api/sun/nio/cs/StreamDecoder.java.html > [2] http://java.sun.com/javase/6/docs/api/java/io/InputStream.html#read(byte[],%20int,%20int) > > > // CODE BEGINS HERE > package inputstreamtest; > > import java.io.BufferedReader; > import java.io.IOException; > import java.io.InputStream; > import java.io.InputStreamReader; > > public class Main { > > public static void main(String[] args) { > BufferedReader in = new BufferedReader(new > InputStreamReader(new FakeInputStream())); > System.out.println("Attempting to read a line..."); > try { > in.readLine(); > } catch (IOException e) { > e.printStackTrace(); > } > } > > private static class FakeInputStream extends InputStream { > @Override > public int read(byte[] b, int off, int len) { > System.out.println("program called inputstream's > read(byte[] b, int off, int len)"); > return 0; > } > > @Override > public int read() throws IOException { > System.out.println("program called inputstream's read()"); > return -1; > } > } > > } > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From cowwoc at bbs.darktech.org Wed May 20 04:45:25 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 06:45:25 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <4A13DF45.7030305@bbs.darktech.org> Kustaa Nyholm wrote: > It is fine. It ain't broken, don't fix it. This is mainly > a documentation issue. When the map and scenery disagree trust > the scenery. This isn't "documentation". It's a specification. The core Java APIs implement it perfectly and expect it to be followed 100% of the time. It is impossible to change it this late in the game. Gili From Kustaa.Nyholm at planmeca.com Wed May 20 06:03:15 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 15:03:15 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A131674.6000906@bbs.darktech.org> Message-ID: > > Guys, I am feeling very frustrated with this whole discussion. I feel your pain as I'm frustrated, not by the discussion which has been conducted in a gentlemanly maner and has entertained me quite a lot, but by people trying to fix what ain't broken. > > 1) There is no doubt that the current implementation breaks the > InputStream API. Well, this is like saying my car is broken because a mouse ate the registration paper (honestly, that happened last winter). There is only a very minor discrepancy between what a few document sentences says and what *useful and practical* functionality the current rxtx/javacomm provides. > A return value of -1 is already mapped to > end-of-stream. For this reason, you *cannot* map the same value to a > timeout. This is basic design-by-contract! I thought we already agreed (talking about read(byte[])) 0 should be returned and AFAIK *is* returned. And this matches the javadoc for CommPort.getInputStream() which says that it return a kind of InputStream where read operations blocks until a timeout occurs OR until any data is available. So it can return even when no data is available. And in that case 0 seems like an appropriate return value. It bends the rules of InputStream a bit, but this is by design, not error. Now, if read() returns -1 in case of timeout this is a dilemma as it does allow differentiation between EOF (whatever it means for serial stream) and timeout. However the 'golden standard', the stream object that javacomm.SerialPort.getInputStream().read(), returns in case of timeout is -1, at least on Windows (just tested it). And we should not brake this compatibility. > > 2) RXTX's implementation does not match javax.comm 100%. > So? Why make it match even less? Most people want compatibility and usability, not semantic / logical correctness at least as far as something as small as serial port API is concerned. Go write your own wrapper if it bother you. > There are > plenty of situations where the two implementations diverge. If there are, please let us know, this is very useful information for any rxtx user so that they can avoid these pitfalls. > I am > frustrated that people want to simultaneously freeze the APIs and fix > issues that *cannot* be fixed purely in the implementation layer. What issues you mean? Off hand I don't recall people asking for fixes that would match your description of "that *cannot* be fixed purely in the implementation layer". Personally, all I've ever wanted from javacomm and rxtx was to be able to access the serial port from Java in platform neutral fashion that allows my code to run on the three major platforms Mac OS X, Linux and Windows. And rxtx delivers just that. > > 3) "Premature optimization is the root of all evil" and yet I see people > complaining that exception handling costs 13 usec. I'm sure you understood that 13 usec was not the point. The point is that exception handling concept has been designed to handle exceptional case which are rare and thus performance of the code when an exception is thrown can be slow. The penalty is not specified but includes creating a new object or several (stack trace) and frequently warned about. Like I said, and I'm sure you understood, at 9600 baud this penalty is not an issue, but in a slower machine (mine was, as stated 2.8 GHz/4GB/1066MHz Core 2 Duo), or different JVM, or JIT not happening (BTW exception handling disturbs JIT) it could be a decade slower. So make it 100 usec and raise baud rate to 1 MBps now merely throwing the exception takes ten times longer than a one character timeout. Many protocols I have programmed have used pauses of less than that to frame messages. IMO it would be serious mistake to use exceptions to handle timeouts. Ever wondered why EOF is signaled with -1 and not an exception... > Java places > emphasizes correctness above performance. If you don't get that you > shouldn't be coding in Java. This is not what I would call parliamentary language. I won't reply. > > More specific replies below... > >> Throwing InterruptedIOException from InputStream.read() is just as >> big sin as it breaks the contract of InterruptedIOException , which >> says that the *thread* that was performing the IO was interrupted. > > A thread getting interrupted is not the same as Thread.interrupt(). Oh yeah? Really? In the context it was used I beg to differ. > My interpretation is that interrupting the operation due to a timeout is a > perfectly legal form of "thread interruption". Even with respect to > Thread.interrupt(), you can't interrupt a thread, only the work it is > executing. > >> Coneceptually I feel throwing an exception is a big sin in a situation >> which is not an error. > > Exceptions refer to "exceptional circumstances" which is not the same > as "errors". By that I mean that the "normally" the method returns > 0-255, but exceptional cases such as timeouts are perfectly legal. But timeout with SerialPort usually is not an exceptional case. But I guess you are fixed to your idea that it is. The important thing however is that it is not for me or you to decide and thus it is not for the API to dictate this. > >> A time out in a serial communication is >> almost always to be excepted since it is used to deal with real, live >> hardware outside the computer > > I disagree. Some application-level protocols don't use timeouts at > all. > Why would your argument be true for serial connections but not sockets? What Sockets and application level protocols have got to do with reading a SerialPort/RS232 port and it's timeouts? > >> So you are advocating adding a new class SerialPortChannel and >> a new method SerialPort.getSerialPortChannel() ? >> >> That would be acceptable in that it would not brake existing code but >> totally unnecessary in my view. I suspect most people turn to rxtx >> as a replacement for javacomm and are only interested in getting the >> job done. And the current API does this with very nicely. I think >> we all have better use for our time than to re-invent a serial port >> API. > > The classic IO api is synchronous whereas NIO channels are > asynchronous. Trying to retrofit timeouts on top of the old APIs will > never be as clean as using NIO which is designed specifically for this > purpose. > You maybe right, but the cure is worse than the disease and the first rule of a good doctor is to "do no harm". What you are concerned about is some semantic details what most of us are concerned with is getting the job done. Here are some more thoughts on using exceptions in case you can be bothered. Quoting from Sun's exception handling tutorial: http://java.sun.com/docs/books/tutorial/essential/exceptions/throwing.html "An Exception indicates that a problem occurred" Now, a timeout, to me, is not a problem, but very often an essential part of the communication protocol. Of course for some in some situations it maybe a problem, but that is not for the (communication) API designer to decide or dictate. To me this spells that timeouts should not throw an exception. Also from the same document: "Here's the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception." Following this guideline would dictate that timeout exception should be a checked exception (because surely almost universally the programmer who enables timeouts (disable by default, remember) can and will handle the timeouts in some reasonable way. *Adding a checked exception toInputStream.reads is not possible.* Again this speaks against throwing an exception in case of timeouts. More in the same vein: http://developer.apple.com/documentation/Performance/Conceptual/CodeSpeed/Ar ticles/TuningJavaCode.html#//apple_ref/doc/uid/TP40002329-DontLinkElementID_ 4 "Exception handling in Java is very slow. ... use exceptions only for truly exceptional cases. Do not use exceptions to indicate simple errors from which your code could otherwise recover. Instead, use them only to indicate abnormal conditions that your code does not know how to handle." cheers Kusti From Kustaa.Nyholm at planmeca.com Wed May 20 06:20:34 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 15:20:34 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A13DDE3.8070703@bbs.darktech.org> Message-ID: > > Not true. Either we follow the InputSteam specification or we define > our own interface. Breaking the specification in this way will trigger > unpredictable bugs. Well bugs are by their very nature unpredictable, what? But seriously who are you to dictate "high road or low road"? Who says we (whoever that 'we' are) must either follow 100% or define our own? If 'we' want to take a middle road we surely can. And I'm all for it. Pursuing 100% clean designs is a fruitless goal and I've got better things to do than keep updating my code base to track an ever changing API in pursuit of an unattainable internal and external purity and correctness. > > Fair enough, but "timeouts in a loop" -- using available() -- don't > break the InputStream specification. So why not use it? If you do not touch the enableTimeout() and enableThreshold() methods the SerialPort.InputStream fulfills the contract to the letter. And if you touch them, it fulfills the commitment that creators of the original API made. > You're supposed to either create your own interface or use NIO for that. > In my view, breaking the superclass contract is always worse than > inconveniencing yourself. Why don't you provide a proof of concept framework of classes and interfaces that are internally and externally consistent for us to scrutinize? I bet it will contain one or two compromises and bending of the rules or be totally out of tune what people need or want to use. cheers Kusti From Steffen.DETTMER at ingenico.com Wed May 20 07:23:40 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 20 May 2009 15:23:40 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A13DDE3.8070703@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> <20090520083008.GH17036@elberon.bln.de.ingenico.com> <4A13DDE3.8070703@bbs.darktech.org> Message-ID: <20090520132339.GB27170@elberon.bln.de.ingenico.com> * cowwoc wrote on Wed, May 20, 2009 at 06:39 -0400: > >>1) There is no doubt that the current implementation breaks the > >>InputStream API. > > > >(which must happen, because InputStream as defined is less usable) > > Not true. Either we follow the InputSteam specification or we define > our own interface. Breaking the specification in this way will trigger > unpredictable bugs. First, I disagree that it is specification because it actually is documentation. A specification would also need to specify how overloaded methods are allowed to change without violating the specification. If javadoc in general would be no documentation but specification obviously no overloaded method could specialise or change any behavior, because as soon as documentation of an overloaded would be needed, it would violate base class specification, in short, no new specification (documentation) could be allowed in any subclass. Theoretically this could be a point (an option to develop a language) but I think it makes not much sense in practice. Also, it often happens that even in specifications there are obvious issues, as soon as everyone does the obvious thing, instead of changing all implementations, the specification is fixed. Or left as it is :) Of course we define an own interface by deriving (implementing) InputStream because specifics will happen. For instance specialised exceptions may be thrown in special new situations not documented (specified) by InputStream. This is what OO is for I think. :) > Actually, the Javadoc for read(byte[]) says that at least one > byte must be read: "If the length of b is zero, then no bytes > are read and 0 is returned; otherwise, there is an attempt to > read at least one byte. If no byte is available because the > stream is at the end of the file, the value -1 is returned; > otherwise, at least one byte is read and stored into b." Strictly speaking, at least for me with my limited foreign language English knowledge, it does not tell what happens if an attempt to read at least one byte was done, no byte was available, the stream is NOT at the end of the file, but still no byte was read. I would accept the point that, strictly speaking, InputStream unconditionally forbids any timeout support (except polling available(), which at least sucks). This actually was my initial point. This prohibition makes no sense and probably was just done by accident (otherwise, docu should tell this) and also is violated if throwing exceptions and also is violated by Java stuff itself. > Fair enough, but "timeouts in a loop" -- using available() -- > don't break the InputStream specification. Yes, and somewhere probably there is some guy who defined InputStream as an Aprils Fool Joke and now cannot sleep because laughing about all those people that poll available() all the time (no delay to gain response time) wasting all CPU resources :-) Anyway, since years InputStream is used and I don't think we can do anything against. I also don't like it, but that's life. If you want a nice language use C++ or Ruby or so ;) SCNR. > >NIO is a bit more BSD socket API style, a step into the direction > >where everything comes from. Next version might take another step > >and reach the goal. Who knows. As far as I know none of the > >issues that lead to NIO (mostly performance and scalability) > >apply to rxtx. > > NIO allows you to select() on a channel with a timeout, which > is the point of contention. Yes, but not if the channel is some InputStream like STDIN, right? Also, as far as I know, you cannot select on own things. So wouldn't work for serial lines or protocols. I think you cannot implement TCP via PPP reasonable and efficiently in (pure) Java, even with NIO as far as I know this is not possible. But there are many things in Java that you cannot implement in Java (even String!). A pitty but otherwise things would be horrible slow. > I'm not sure I understand. I get that you dislike that > InputStream doesn't provide facilities for non-blocking reads > but that is just life. You're supposed to either create your > own interface or use NIO for that. In my view, breaking the > superclass contract is always worse than inconveniencing > yourself. I think, when we would discuss NIO, we would also quickly find sufficient issues with it (I think we had this discussion already) and that we do not (really :)) break the superclass contract (of InputStream). We just add possibility to support timeout (by new method setReceiveTimeout() and overloaded read()). :-) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed May 20 07:40:03 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 20 May 2009 15:40:03 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> Message-ID: <20090520134002.GC27170@elberon.bln.de.ingenico.com> (OT) * Kustaa Nyholm wrote on Wed, May 20, 2009 at 15:03 +0300: > Ever wondered why EOF is signaled with -1 and not an exception... Yeah... I always wonder why Java has so many issues that were already discussed and solved since ages in POSIX or ANSI-C or C++ /before/ java was started. On POSIX reads -1 is error. You call some select(2) before. If select tells ready-for-read and you read EOF, read returns 0 bytes. This is at least a bit intuitive - and seems to work in all cases. Seeing a file descriptor like a class IMHO works. read(fd, ..) could be understood as fd.read(). When looking how great in overall this works I feel deep respect for all the people who invented that :) > > Java places emphasizes correctness above performance. This is definitely wrong. Much of Java Core Tech is uglyDirtyNasty because of performance. For instance you cannot overload String (reasonable). Operator overloading is not possible except for String.operator+ (concatenation). Implicite conversion is possible by Object().toString() but nowhere else. You cannot implement a toLong() and have it be called implicitely. String automatically uses StringBuffer for operations, again a hack you have no chance to copy or influence. You cannot pass scalars like long by reference, you are force to pass them by value. You cannot pass Objects by value, you are forced to pass them by reference. Except your object is e.g. a Long, then it is passed by value. You cannot implement any of that in Java itself. It is Mr. JVM in person :) who knows those hacks and how to workaround / pass by. Also great is Object.clone(). Works without overloading. How does Object.clone() know the members of the child class? Because it knows the structure and hacks it to match. Same for serialisation and deserialisation. Object construction. Why can an Object call a method overloaded in a child class in its constructor? Interesting is what happens: the child class is already `half constructed', i.e. working except member initialisation and its constructor was not run. But a method can be invoked. This is not clean this sucks but anyway. We could continue this quite some time (Inner Class hacks, Generics hacks, forced GC, no RAII support would be next) :-) Honestly, a student would not pass a university test with so much hacking (I hope ;)). oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From michael.erskine at ketech.com Wed May 20 07:45:13 2009 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 20 May 2009 14:45:13 +0100 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0D6BA5.8020209@bbs.darktech.org> References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <06BA3262D918014F9183B66425D5A8D463C3C2E90A@no-sv-03.ketech.local> I wander in to find a gazillion posts about whether RXTX is breaking some rule or other. I don't have time to read and argue the toss over which way of doing something may be more correct. As far as I'm concerned (and, I venture, the other developers in industry) whatever RXTX does _IS_ the right thing. I don't fancy trying to justify the costs that would be incurred in the respecifying, rewriting, and retesting of an absolute ton of SIL2 software. Please, let's not screw things up. Regards, Michael Erskine. From Kustaa.Nyholm at planmeca.com Wed May 20 07:58:12 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 16:58:12 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090520134002.GC27170@elberon.bln.de.ingenico.com> Message-ID: Just to clarify Steffen's mail, this was not my sentence: >>> Java places emphasizes correctness above performance. to which he responded: > > This is definitely wrong. Much of Java Core Tech is > uglyDirtyNasty because of performance. > > Honestly, a student would not pass a university test with so much > hacking (I hope ;)). > and with which I agree. cheers Kusti From Kustaa.Nyholm at planmeca.com Wed May 20 08:13:54 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 17:13:54 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <06BA3262D918014F9183B66425D5A8D463C3C2E90A@no-sv-03.ketech.local> Message-ID: Michael Erskine: > I wander in to find a gazillion posts about whether RXTX is breaking some rule > or other. I don't have time to read and argue the toss over which way of doing > something may be more correct. I've participated in the discussion just for that reason, trying to prevent anyone 'correcting' this API. > > As far as I'm concerned (and, I venture, the other developers in industry) > whatever RXTX does _IS_ the right thing. Indeed! > > I don't fancy trying to justify the costs that would be incurred in the > respecifying, rewriting, and retesting of an absolute ton of SIL2 software. > Hear, hear! > Please, let's not screw things up. Yeah, let's not screw this up. From cowwoc at bbs.darktech.org Wed May 20 08:40:11 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 10:40:11 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090520132339.GB27170@elberon.bln.de.ingenico.com> References: <4A131674.6000906@bbs.darktech.org> <20090520083008.GH17036@elberon.bln.de.ingenico.com> <4A13DDE3.8070703@bbs.darktech.org> <20090520132339.GB27170@elberon.bln.de.ingenico.com> Message-ID: <4A14164B.6040000@bbs.darktech.org> Steffen DETTMER wrote: > First, I disagree that it is specification because it actually is > documentation. A specification would also need to specify how > overloaded methods are allowed to change without violating the > specification. If javadoc in general would be no documentation > but specification obviously no overloaded method could specialise > or change any behavior, because as soon as documentation of an > overloaded would be needed, it would violate base class > specification, That is incorrect. Design by Contract allows subclasses to weaken preconditions, strengthen postconditions and strengthen invariants -- all without violating the superclass specification. > Also, it often happens that even in specifications there are > obvious issues, as soon as everyone does the obvious thing, > instead of changing all implementations, the specification is > fixed. Or left as it is :) As far as I know, this has never been done for core Java classes because doing so would break backwards compatibility. This is discussed at length in the Effective Java book. > Of course we define an own interface by deriving (implementing) > InputStream because specifics will happen. For instance > specialised exceptions may be thrown in special new situations > not documented (specified) by InputStream. This is what OO is for > I think. :) A subclass may not throw any new (checked) exceptions. Doing so would violating the superclass specification. You could always throw a subclass of IOException but that's about it. The reason this only applies to checked exceptions is that all methods throw RuntimeException by default. >> Actually, the Javadoc for read(byte[]) says that at least one >> byte must be read: "If the length of b is zero, then no bytes >> are read and 0 is returned; otherwise, there is an attempt to >> read at least one byte. If no byte is available because the >> stream is at the end of the file, the value -1 is returned; >> otherwise, at least one byte is read and stored into b." > > Strictly speaking, at least for me with my limited foreign > language English knowledge, it does not tell what happens if an > attempt to read at least one byte was done, no byte was > available, the stream is NOT at the end of the file, but still no > byte was read. The sentence above reads "This method blocks until input data is available, end of file is detected, or an exception is thrown." In other words, you must block. > I would accept the point that, strictly speaking, InputStream > unconditionally forbids any timeout support (except polling > available(), which at least sucks). > > This actually was my initial point. This prohibition makes no > sense and probably was just done by accident (otherwise, docu > should tell this) and also is violated if throwing exceptions and > also is violated by Java stuff itself. If a timeout could be said to be a new kind of end-of-stream (with the resulting behavior being absolutely identical) then using -1 might be fine. Unfortunately, this is not the case. End-of-stream indicates that the InputStream will never return bytes ever again. Timeouts violate this guarantee. With respect to exceptions, you are allowed to throw any subclass of IOException for the reasons mentioned in Design by Contract. >> Fair enough, but "timeouts in a loop" -- using available() -- >> don't break the InputStream specification. > > Yes, and somewhere probably there is some guy who defined > InputStream as an Aprils Fool Joke and now cannot sleep because > laughing about all those people that poll available() all the > time (no delay to gain response time) wasting all CPU resources > :-) InputStream works perfectly fine for synchronous reading. If you want asynchronous reading you are supposed to use NIO channels. >> NIO allows you to select() on a channel with a timeout, which >> is the point of contention. > Yes, but not if the channel is some InputStream like STDIN, > right? Also, as far as I know, you cannot select on own things. > So wouldn't work for serial lines or protocols. I don't understand what you mean. You can get a Channel for System.in using java.nio.channels.Channels. > I think you cannot implement TCP via PPP reasonable and > efficiently in (pure) Java, even with NIO as far as I know this > is not possible. But there are many things in Java that you > cannot implement in Java (even String!). You can find TCP/PPP implementations in Java on the web. You don't need them most of the time because the OS provides an implementation for free. > I think, when we would discuss NIO, we would also quickly find > sufficient issues with it (I think we had this discussion > already) and that we do not (really :)) break the superclass > contract (of InputStream). We just add possibility to support > timeout (by new method setReceiveTimeout() and overloaded read()). Again, I suggest you read up on Design by Contract. You will find out exactly why you are not allowed to overload the -1 return code in this way. Gili From cowwoc at bbs.darktech.org Wed May 20 08:46:08 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 10:46:08 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <06BA3262D918014F9183B66425D5A8D463C3C2E90A@no-sv-03.ketech.local> References: <4A0D6BA5.8020209@bbs.darktech.org> <06BA3262D918014F9183B66425D5A8D463C3C2E90A@no-sv-03.ketech.local> Message-ID: <4A1417B0.3040903@bbs.darktech.org> Michael, You have a choice to either break compatibility with old versions of RXTX or break compatibility with all other libraries in existence. Both options suck, but the latter involves breaking even more code. Right now you cannot safely pass RXTX's InputStream into any other library in existence. Gili Michael Erskine wrote: > I wander in to find a gazillion posts about whether RXTX is breaking some rule or other. I don't have time to read and argue the toss over which way of doing something may be more correct. > > As far as I'm concerned (and, I venture, the other developers in industry) whatever RXTX does _IS_ the right thing. > > I don't fancy trying to justify the costs that would be incurred in the respecifying, rewriting, and retesting of an absolute ton of SIL2 software. > > Please, let's not screw things up. > > Regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From johnny.luong at trustcommerce.com Wed May 20 09:55:03 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Wed, 20 May 2009 08:55:03 -0700 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> Message-ID: <4A1427D7.2020906@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Trent Jarvi wrote: | On Tue, 19 May 2009, cowwoc wrote: |>> A time out in a serial communication is |>> almost always to be excepted since it is used to deal with real, live |>> hardware outside the computer |> I disagree. Some application-level protocols don't use timeouts at all. |> Why would your argument be true for serial connections but not sockets? |> | | Hi Gili | | One fundamental difference between sockets, file io and RS232 | communication is that sockets and file systems provide error handling. | If a packet is lost, it is resent without the java API knowing about it. | | RS232 is actually an electrical signal standard. Serial communication | exposes a UART without any meaningful error handling and cludgy error | reporting. | | Given the above, ignoring timeouts is not really a valid rxtx level | option. We could have a new option/method that allows you to get an | InputStream or Channel that behaves as you wish. | | If we change the InputStream returned by getInputStream(), that would | be change in the API (version 3.0) that forks our userbase. | | So I guess my question is whether or not you are trying to change the | object returned by getInputStream or just looking for a means to get a | different object you would like to define be returned. | | The later is far easier to accommodate. | | -- | Trent Jarvi | tjarvi at qbang.org | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Trent, For sockets, I'm not so sure there is really any guarantees short of actually monitoring it externally. For example, write() in outputstream doesn't return any value whatsoever -- you might get an exception but in the worse case, it just tells you something bad happened and in the best case, you might be able to catch some implementation specific exception. ~ The same could apply to files too but the magnitude of failure there are significantly lower. But this is sort of a digression... My thinking is that we just sort of keep the interface so that we don't disrupt people who use the methods (our software actually polls from the serial port version of the InputStream/OutputStream as a side effect of the quirkyness involved with the timeout -- this is because the USB-serial thing we had to work with really sucks) but add an additional interface similar to what is SocketChannel and proceed from there. There is a lot of work involved in it though and as it has been pointed out by others, maybe most can live with the hacks involved in the current implementation. Best, Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoUJ9cACgkQnQTBLXttTeVYlQCfcvIHMh1W1kcna5vUtg20dWWK flMAn2WZk03PSgYT1KkHMLp8TlLRtcxn =YeMI -----END PGP SIGNATURE----- From michaeltandy at googlemail.com Wed May 20 09:57:36 2009 From: michaeltandy at googlemail.com (Michael Tandy) Date: Wed, 20 May 2009 16:57:36 +0100 Subject: [Rxtx] Rxtx native library loading In-Reply-To: References: <302aa0340905190733r4009e394v335b3ef47d84ffb5@mail.gmail.com> Message-ID: <302aa0340905200857v53642f58je6932c3315b8a30d@mail.gmail.com> There's also a bug in my code; it worked fine swapping between my Windows machine and my 64-bit Linux machine, but trying to run the 64-bit library on my 32-bit Linux laptop (obviously) doesn't work. So, it needs to detect more architectures and handle them more cleverly :) Still, if your next release will do that, I guess I don't have to fix my code :) Thanks Michael 2009/5/20 Trent Jarvi : > > Hi Michael, > > We will be putting a patch like yours in as soon as we release 2.2. ?The > release was going to be mothers day but I got caught up :) ?I hope to do it > next weekend. ?After that we will be looking at web installs which overlaps > with your solution. > > -- > Trent Jarvi > tjarvi at qbang.org > From cowwoc at bbs.darktech.org Wed May 20 10:04:32 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 12:04:32 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A1427D7.2020906@trustcommerce.com> References: <4A131674.6000906@bbs.darktech.org> <4A1427D7.2020906@trustcommerce.com> Message-ID: <4A142A10.1090302@bbs.darktech.org> Johnny Luong wrote: > My thinking is that we just sort of keep the interface so that we don't > disrupt people who use the methods (our software actually polls from the > serial port version of the InputStream/OutputStream as a side effect of > the quirkyness involved with the timeout -- this is because the > USB-serial thing we had to work with really sucks) but add an additional > interface similar to what is SocketChannel and proceed from there. We could also deprecate getInputStream() in favor of another method that returns a fixed implementation. This will allow existing code to keep on working while providing a migration route for RXTX 3.0. Gili From jerrypedersen at telus.net Wed May 20 10:10:00 2009 From: jerrypedersen at telus.net (Jerry Pedersen) Date: Wed, 20 May 2009 09:10:00 -0700 Subject: [Rxtx] 38400 Baud - UnsupportedCommOperationexception: Invalid Parameter Message-ID: <4A142B58.4050909@telus.net> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090520/0ac89fb9/attachment-0005.html From bill7007 at gmail.com Wed May 20 11:20:13 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Wed, 20 May 2009 13:20:13 -0400 Subject: [Rxtx] 38400 Baud - UnsupportedCommOperationexception: Invalid Parameter In-Reply-To: <4A142B58.4050909@telus.net> References: <4A142B58.4050909@telus.net> Message-ID: Hi Jerry, You might check out: [Rxtx] Baud rate fixes in 2.2pre2 breaks 38400 on some Linux devices It has a link to a patch on 2.2pre that got me around a similar problem. +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090520/046aa29d/attachment-0005.html From Kustaa.Nyholm at planmeca.com Wed May 20 12:23:41 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 May 2009 21:23:41 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A1417B0.3040903@bbs.darktech.org> References: <4A0D6BA5.8020209@bbs.darktech.org> <06BA3262D918014F9183B66425D5A8D463C3C2E90A@no-sv-03.ketech.local>, <4A1417B0.3040903@bbs.darktech.org> Message-ID: <5D23E5B41156B646B2E1A7C2BBA916F317119151AF@SRVFIHKIEXB01.pmgroup.local> Gili wrote: >You have a choice to either break compatibility with old versions of >RXTX or break compatibility with all other libraries in existence. Both >options suck, but the latter involves breaking even more code. Or, the third option, leave it well alone! Keep it compatible existing code that is actually using rxtx instead of just worrying about it being correct to a T. Use it as the creators meant it to be used. Stop worrying about this. > Right now you cannot safely pass RXTX's InputStream into any other >library in existence. Now that is blatantly untrue. If timeouts are not enable you can pass it safely to any library. When timeouts are enabled *some* libraries will not work, some will. If you worry or encounter such a situation you can then do some wrapper magic. But for pete's sake, let us not disturb the happy life of rxtx users with well intentioned but misguided zealozy. I wonder too how often SerialPort input stream is passed to *any* library? I certainly haven't done that ever. The way I vision people are using serial port is to talk directly to it doing most if not all of the protocol handling with custom code, not with a library. If pass it (the input stream) to a library that chokes on read returning 0 it is rather your fault for not reading what the javadoc for SerialPort.getInputStream says! cheers Kusti From tjarvi at qbang.org Wed May 20 17:18:37 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 May 2009 17:18:37 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A142A10.1090302@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> <4A1427D7.2020906@trustcommerce.com> <4A142A10.1090302@bbs.darktech.org> Message-ID: On Wed, 20 May 2009, cowwoc wrote: > Johnny Luong wrote: >> My thinking is that we just sort of keep the interface so that we don't >> disrupt people who use the methods (our software actually polls from the >> serial port version of the InputStream/OutputStream as a side effect of >> the quirkyness involved with the timeout -- this is because the >> USB-serial thing we had to work with really sucks) but add an additional >> interface similar to what is SocketChannel and proceed from there. > > We could also deprecate getInputStream() in favor of another method > that returns a fixed implementation. This will allow existing code to > keep on working while providing a migration route for RXTX 3.0. > Hi Gili, Good. I think it is time to see the method and InputStream. From there, we can discuss options in 3.0. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Wed May 20 18:49:50 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 20 May 2009 20:49:50 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A131674.6000906@bbs.darktech.org> <4A1427D7.2020906@trustcommerce.com> <4A142A10.1090302@bbs.darktech.org> Message-ID: <4A14A52E.7080701@bbs.darktech.org> Trent Jarvi wrote: > Good. > > I think it is time to see the method and InputStream. From there, we > can discuss options in 3.0. I propose the following: 1) add "CommPortChannel getChannel()" 2) deprecate getInputStream() and enableReceiveTimeout() in favor of getChannel() 3) getChannel() will return a class that implements the same interfaces as SocketChannel. It will allow both blocking and non-blocking I/O operations. 4) In RXTX 3.0 getInputStream() will return an InputStream that always blocks on reads and the method will be undeprecated. Gili From tjarvi at qbang.org Wed May 20 19:27:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 May 2009 19:27:50 -0600 (MDT) Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A14A52E.7080701@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> <4A1427D7.2020906@trustcommerce.com> <4A142A10.1090302@bbs.darktech.org> <4A14A52E.7080701@bbs.darktech.org> Message-ID: On Wed, 20 May 2009, cowwoc wrote: > Trent Jarvi wrote: >> Good. >> >> I think it is time to see the method and InputStream. From there, we can >> discuss options in 3.0. > > I propose the following: > > 1) add "CommPortChannel getChannel()" > 2) deprecate getInputStream() and enableReceiveTimeout() in favor of > getChannel() > 3) getChannel() will return a class that implements the same interfaces as > SocketChannel. It will allow both blocking and non-blocking I/O operations. > 4) In RXTX 3.0 getInputStream() will return an InputStream that always blocks > on reads and the method will be undeprecated. > Hi Gili, RXTX 3.0 would be the soonest we would start any deprecation if it is agreed upon. So far, I don't think there is near enough buy in. But you can have getChannel now. If it is obviously a right solution, you may see people reconsider their opinions. Timeouts wont go away or be deprecated but they could throw unsupported io exceptions for the life of the inputstream returned by getChannel for obvious reasons. Let people try it and give feedback. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Thu May 21 01:19:05 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 21 May 2009 10:19:05 +0300 Subject: [Rxtx] InputStream timeouts Message-ID: <5D23E5B41156B646B2E1A7C2BBA916F317119151B4@SRVFIHKIEXB01.pmgroup.local> Hi Gili, please don't start patronizing. I've been around OO and Design by Contract from around 1986 starting by implementing our own Smalltalk environment. By then I had been writing software for ten years. It is not that I don't understand what you are saying. It is just that I'm not (any more ?!) an OO or DbC zealot. In real world most concepts seem to break down when applied over too wide field. Newtons laws are fine until you get to quantum level. OO is great, but at least so far, it seems that making everything (think integers) objects was a mistake in Smalltalk. You maybe right on the theoretical level, but who cares? Who are you to impose *your* standards on the rest of us? *Every good desing is a compromize.* In this instance I'm 100% sure that the designers of javacomm were well aware of the issues you are complaining about and considered these and many other issues. And their compromise is what we have today.It would belittling them to think otherwise. And to me, even if I think I see where you are coming from, the compromise seem almost perfect for the given problem. To me it is very natural and works almost perfectly despite (or because ?) of the little bending of the rules. Like Steffen(?) wrote here earlier : that (compromise to make it work) is Java all over. And I firmly believe that that is what made Java a success, just like C. Not the prettiest girls in town but very popular... cheers Kusti ________________________________________ From: cowwoc [cowwoc at bbs.darktech.org] Sent: Wednesday, May 20, 2009 9:42 PM To: Kustaa Nyholm Subject: Re: [Rxtx] InputStream timeouts Do me a favor and let me know once you read about Design by Contract. Only then will you be able to understand why RXTX cannot redefine how InputStream works. If subclasses are allowed to modify the contract in an arbitrary manner it defeats the entire concept of Class Inheritance and formal Interfaces. Gili Kustaa Nyholm wrote: > Gili wrote: > >> You have a choice to either break compatibility with old versions of >> RXTX or break compatibility with all other libraries in existence. Both >> options suck, but the latter involves breaking even more code. > > Or, the third option, leave it well alone! Keep it compatible existing code > that is actually using rxtx instead of just worrying about it being correct > to a T. Use it as the creators meant it to be used. Stop worrying about > this. > > >> Right now you cannot safely pass RXTX's InputStream into any other >> library in existence. > > Now that is blatantly untrue. If timeouts are not enable you can pass > it safely to any library. When timeouts are enabled *some* libraries will > not work, some will. If you worry or encounter such a situation you > can then do some wrapper magic. But for pete's sake, let us not disturb > the happy life of rxtx users with well intentioned but misguided zealozy. > > I wonder too how often SerialPort input stream is passed to *any* library? > > I certainly haven't done that ever. > > The way I vision people are using serial port is to talk directly to it > doing most if not all of the protocol handling with custom code, > not with a library. If pass it (the input stream) to a library that chokes on > read returning 0 it is rather your fault for not reading what > the javadoc for SerialPort.getInputStream says! > > cheers Kusti > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Kustaa.Nyholm at planmeca.com Thu May 21 01:20:42 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 21 May 2009 10:20:42 +0300 Subject: [Rxtx] InputStream timeouts Message-ID: <5D23E5B41156B646B2E1A7C2BBA916F317119151B5@SRVFIHKIEXB01.pmgroup.local> Gili wrote: >You have a choice to either break compatibility with old versions of >RXTX or break compatibility with all other libraries in existence. Both >options suck, but the latter involves breaking even more code. Or, the third option, leave it well alone! Keep it compatible existing code that is actually using rxtx instead of just worrying about it being correct to a T. Use it as the creators meant it to be used. Stop worrying about this. > Right now you cannot safely pass RXTX's InputStream into any other >library in existence. Now that is blatantly untrue. If timeouts are not enable you can pass it safely to any library. When timeouts are enabled *some* libraries will not work, some will. If you worry or encounter such a situation you can then do some wrapper magic. But for pete's sake, let us not disturb the happy life of rxtx users with well intentioned but misguided zealozy. I wonder too how often SerialPort input stream is passed to *any* library? I certainly haven't done that ever. The way I vision people are using serial port is to talk directly to it doing most if not all of the protocol handling with custom code, not with a library. If pass it (the input stream) to a library that chokes on read returning 0 it is rather your fault for not reading what the javadoc for SerialPort.getInputStream says! cheers Kusti From Kustaa.Nyholm at planmeca.com Thu May 21 01:49:36 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 21 May 2009 10:49:36 +0300 Subject: [Rxtx] InputStream timeouts - opinions on breaking compatibility? Message-ID: <5D23E5B41156B646B2E1A7C2BBA916F317119151B6@SRVFIHKIEXB01.pmgroup.local> Hi, changed the subject line a bit because I suspect most people have tuned out of this discussion and yet I feel that it is the very people who's input is needed. A month or so ago a lot of people chimed in by telling *what* they do with rxtx, now I would really be interesting to know *how* people are using rxtx? More specifically and relevant to this discussion: 1) are timeouts used? 2) how are they handled? 3) are SerialPort InputStreams passed to library functions? 4) have there been problems (in 3 above)? 5) how would you feel if you would need to rework your code to work with the 'improved' API? The proposal we have (by Gili) is: > 1) add "CommPortChannel getChannel()" This I do not mind so much as I do not need to touch my code. > 2) deprecate getInputStream() and enableReceiveTimeout() in favor of > getChannel() This I object to very much. One of my coding 'rules' say do-not-use-deprecated methods. An other rule says that my compiles-should-be-clean, so this would need me to change my code. Also, this is imposing and force feeding things to people who can't appreciate the beauty of the 'improvements' and are against them. > 3) getChannel() will return a class that implements the same interfaces as > SocketChannel. It will allow both blocking and non-blocking I/O operations. As I will not be using that (getChannel()) I don't care so much, but I bet this will be a new can worms having just the same sort of issues and compromises as we have been discussing here. But it would really be educational and fun to see proposers eat their own dog meat, so yes, let's do this! > 4) In RXTX 3.0 getInputStream() will return an InputStream that always blocks > on reads and the method will be undeprecated. > Just great, this is the top, I'm totally against this. Not only did (2) above require me to rework my code but now in phase two I would need to rework my code again to comply with yet another API change. There has to be better things in life and coding than tracking ever changing APIs! I'm involved in several projects ranging from a few thousand lines to several thousand hand written classes. Javacomm and rxtx play a small but crucial part in these. I would very much like to spend time on improving the applications instead of tracking changes in different APIs (not limited to rxtx). Especially changes that IMO only bring internal beauty . Our current code works and has been debugged to with the current API design, no compelling reason has been put forward to change the API and throw away the (albeit not so big) investment in learning to use the current API and making our code to work with it. All I care is that I have a cross platform serial port API that is stable and works as advertised, and which I do not have to implement and test on all the platforms. So far rxtx has been just wonderful, let's keep it that way. my 2 snt worth, cheers Kusti From michaeltandy at googlemail.com Thu May 21 05:48:44 2009 From: michaeltandy at googlemail.com (Michael Tandy) Date: Thu, 21 May 2009 12:48:44 +0100 Subject: [Rxtx] Buffer overflow caused by fhs_lock error message Message-ID: <302aa0340905210448v46b7ee61j58787b10500411b@mail.gmail.com> When, on Linux, one attempts to open a device such as /dev/ttyUSB71 and the device is locked, Java crashes with this error message: *** buffer overflow detected ***: java terminated ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7ead6d8] /lib/tls/i686/cmov/libc.so.6[0xb7eab800] /lib/tls/i686/cmov/libc.so.6[0xb7eaaef8] /lib/tls/i686/cmov/libc.so.6(_IO_default_xsputn+0xc8)[0xb7e20a78] /lib/tls/i686/cmov/libc.so.6(_IO_vfprintf+0x6f3)[0xb7df30b3] /lib/tls/i686/cmov/libc.so.6(__vsprintf_chk+0xa4)[0xb7eaafa4] /lib/tls/i686/cmov/libc.so.6(__sprintf_chk+0x2d)[0xb7eaaeed] /home/michael/Documents/asdf/lib/librxtxSerial.so(fhs_lock+0x1c2)[0xb4b82cf2] /home/michael/Documents/asdf/lib/librxtxSerial.so(Java_gnu_io_RXTXCommDriver_testRead+0x80)[0xb4b838a0] This is caused because trying to sprintf the error message, the device name, the error description, the newline and then null terminate the string overflows the 80 characters allocated. The problem code seems to be: char message[80]; sprintf( message,"RXTX fhs_lock() Error: creating lock file: %s: %s\n", file, strerror(errno) ); A switch to the buffer-overflow-proof snprintf function fixes the problem by truncating the error message if it exceeds 79 characters: char message[80]; snprintf( message, 80, "RXTX fhs_lock() Error: creating lock file: %s: %s\n", file, strerror(errno) ); A patch is attached to apply this fix - although there might be other bugs of this class in rxtx; it might be worth applying this fix anywhere sprintf is currently used. Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: overflowpatch.diff Type: application/octet-stream Size: 1133 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090521/3a487d21/attachment-0005.obj From rxtx at qbang.org Thu May 21 09:48:47 2009 From: rxtx at qbang.org (VIAGRA ® Official Site) Date: Thu, 21 May 2009 09:48:47 -0600 Subject: [Rxtx] Dear rxtx@qbang.org SALE 77% 0FF on Pfizer ! Message-ID: <200905211548.n4LFmltZ029873@rxtx.qbang.org> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090521/c9af7fb9/attachment-0004.html From Klaus.Kierer at Tiscover.com Thu May 21 10:02:52 2009 From: Klaus.Kierer at Tiscover.com (Kierer, Klaus) Date: Thu, 21 May 2009 18:02:52 +0200 Subject: [Rxtx] Abwesenheitsnotiz: URL Filtering: Re: Dear rxtx@qbang.org SALE 77% 0FF on Pfizer ! Message-ID: <65FE44E2CAED5742B96A161F3703A5390861B0F5@ibk-tis-mx-01.tiscover.corp> Vielen Dank f?r Ihre Nachricht. Ich bin leider bis Montag, 25 Mai au?er Haus und werde mich erst anschlie?end um Ihr Anliegen k?mmern k?nnen. In dringenden F?llen senden Sie daher bitte ein Email an alexander.sommer at tiscover.com. Danke. Mit freundlichen Gr??en Klaus Kierer www.tiscover.com Thank you for your message. I am currently not contactable until Monday, 25th of May and thus cannot respond to your message until then. If your enquiry is urgent, please contact alexander.sommer at tiscover.com. Thank you. Kind Regards Klaus Kierer www.tiscover.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090521/0d4f9c57/attachment-0004.html From pixue_breaker at hotmail.com Fri May 22 02:35:41 2009 From: pixue_breaker at hotmail.com (=?iso-8859-1?Q?Samuel_Ovia=F1o_Su=E1rez?=) Date: Fri, 22 May 2009 08:35:41 +0000 Subject: [Rxtx] porting rxtx to avr32-linux Message-ID: Hi! I'm trying to port rxtx to avr32-linux. My objetive is executing a serial comm app with jamvm running on avr32-linux platform so i need the suitable librxtxSerial.so for this. I have started to work in that following the next steps: 1. input : ./autogen.sh --host=avr32-linux --target=avr32-linux output : You should update your `aclocal.m4' by running aclocal acinclude.m4:6193: the serial number must appear before any macro definition 2. I updated aclocal comment out line 6193 of acinlcude.m4 and then i typed 'aclocal' 3. input: ./configure --host=avr32-linux --target=avr32-linux output: the makefile with avr32-linux settings After, i tried to 'make install' but compilation process stopped with this error: /home/samuel/Escritorio/rxtx-2.1-7r2/./src/SerialImp.h:441: error: expected declaration specifiers or '...' before 'wchar_t' avr32-linux-gcc -I/home/samuel/Escritorio/rxtx-2.1-7r2 -Iavr32-unknown-linux-gnu -I. -I/usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/include -I/usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/include/./ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c /home/samuel/Escritorio/rxtx-2.1-7r2/./src/fuserImp.c -fPIC -DPIC -o /home/samuel/Escritorio/rxtx-2.1-7r2/avr32-unknown-linux-gnu/.libs/fuserImp.o libtool: link: `/home/samuel/Escritorio/rxtx-2.1-7r2/avr32-unknown-linux-gnu/SerialImp.lo' is not a valid libtool object make: *** [avr32-unknown-linux-gnu/librxtxSerial.la] Error 1 What's wrong? Thanks in advance, Pixueto _________________________________________________________________ ?Qu?tate unos clics! Ahora, Internet Explorer 8 tiene todo lo que te gusta de Windows Live ?Cons?guelo gratis! http://ie8.msn.com/microsoft/internet-explorer-8/es-es/ie8.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090522/87e7bc4d/attachment-0004.html From tjarvi at qbang.org Fri May 22 09:05:44 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 May 2009 09:05:44 -0600 (MDT) Subject: [Rxtx] porting rxtx to avr32-linux In-Reply-To: References: Message-ID: On Fri, 22 May 2009, Samuel Ovia?o Su?rez wrote: > Hi! > > I'm trying to port rxtx to avr32-linux. My objetive is executing a serial comm app with jamvm running on avr32-linux platform so i need the suitable > librxtxSerial.so for this. I have started to work in that following the next steps: > > 1. input : ./autogen.sh --host=avr32-linux --target=avr32-linux > ??? output : You should update your `aclocal.m4' by running aclocal > ?????????????????? acinclude.m4:6193: the serial number must appear before any macro definition > > 2. I updated aclocal comment out line 6193 of acinlcude.m4 and then i typed 'aclocal' > > 3. input: ./configure --host=avr32-linux --target=avr32-linux > ??? output: the makefile with avr32-linux settings > > After, i tried to 'make install' but compilation process stopped with this error: > > /home/samuel/Escritorio/rxtx-2.1-7r2/./src/SerialImp.h:441: error: expected declaration specifiers or '...' before 'wchar_t' > ?avr32-linux-gcc -I/home/samuel/Escritorio/rxtx-2.1-7r2 -Iavr32-unknown-linux-gnu -I. -I/usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/include > -I/usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/include/./ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c > /home/samuel/Escritorio/rxtx-2.1-7r2/./src/fuserImp.c? -fPIC -DPIC -o /home/samuel/Escritorio/rxtx-2.1-7r2/avr32-unknown-linux-gnu/.libs/fuserImp.o > libtool: link: `/home/samuel/Escritorio/rxtx-2.1-7r2/avr32-unknown-linux-gnu/SerialImp.lo' is not a valid libtool object > make: *** [avr32-unknown-linux-gnu/librxtxSerial.la] Error 1 > > What's wrong? > > Thanks in advance, Hi Pixueto I don't think autogen.sh takes arguments. Perhaps you are used to a newer version of the same script. The arguments should be ignored. .m4 files are beyond me. Your hack is typical of what I do but I've not made rules before. Is line 441 in SerialImp.h 'extern int mexPrintf( const char *, ... );" ? If so, you do not want to turn on DEBUG_MW. Those functions are an older way of printing debug information in MATLAB. -- Trent Jarvi tjarvi at mathworks.com From Bob_Jacobsen at lbl.gov Fri May 22 10:05:12 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Fri, 22 May 2009 09:05:12 -0700 Subject: [Rxtx] InputStream timeouts - opinions on breaking compatibility? In-Reply-To: <5D23E5B41156B646B2E1A7C2BBA916F317119151B6@SRVFIHKIEXB01.pmgroup.local> References: <5D23E5B41156B646B2E1A7C2BBA916F317119151B6@SRVFIHKIEXB01.pmgroup.local> Message-ID: At 10:49 AM +0300 5/21/09, Kustaa Nyholm wrote: >A month or so ago a lot of people chimed in by telling *what* they >do with rxtx, >now I would really be interesting to know *how* people are using rxtx? > >More specifically and relevant to this discussion: > >1) are timeouts used? Yes, because on some platforms/protocols it's the only known way to get the last read character. >2) how are they handled? Just repeat the read >3) are SerialPort InputStreams passed to library functions? Yes. >4) have there been problems (in 3 above)? No. >5) how would you feel if you would need to rework your code to work >with the 'improved' API? If you changed the API? Very, very unhappy. >The proposal we have (by Gili) is: > > > 1) add "CommPortChannel getChannel()" > No objection, but no plans to use on any reasonable timescale. > > 2) deprecate getInputStream() and enableReceiveTimeout() in favor of > > getChannel() > You should only deprecate something you intend to eventually remove. What's the reason to _remove_ these? They do what they do. > > 3) getChannel() will return a class that implements the same interfaces as > > SocketChannel. It will allow both blocking and non-blocking I/O operations. > If this is going to be done, somebody should _first_ write a very detailed API of what the SocketChannel interface "means" for serial communications (which isn't just bytes and EOF). > > 4) In RXTX 3.0 getInputStream() will return an InputStream that >always blocks >> on reads and the method will be undeprecated. >> Very, very opposed to this. If you want to provide another interface, fine, but don't hijack an existing one. This will result in significant maintenance problems as people have to mix and match various versions of RXTX for concurrent use. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From cowwoc at bbs.darktech.org Fri May 22 10:29:39 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 22 May 2009 12:29:39 -0400 Subject: [Rxtx] InputStream timeouts - opinions on breaking compatibility? In-Reply-To: References: <5D23E5B41156B646B2E1A7C2BBA916F317119151B6@SRVFIHKIEXB01.pmgroup.local> Message-ID: <4A16D2F3.2000607@bbs.darktech.org> Bob Jacobsen wrote: >> 3) are SerialPort InputStreams passed to library functions? > > Yes. Related question: which classes do you pass RXTX's InputStream to? Gili From pixue_breaker at hotmail.com Sat May 23 11:35:51 2009 From: pixue_breaker at hotmail.com (=?iso-8859-1?Q?Samuel_Ovia=F1o_Su=E1rez?=) Date: Sat, 23 May 2009 17:35:51 +0000 Subject: [Rxtx] porting rxtx to avr32-linux Message-ID: Hi!, I think i achieve complete the porting. I followed the next steps: - At SerialImp.h , comment out line 441 - At I2CImp.c , comment out lines 96 to 100 - At RawImp.c , comment out lines 240 to 244 and line 65 - At RS485Imp.c, comment out lines 96 to 100 Then i did make install and the output was the following: ---------------------------------------------------------------------- Libraries have been installed in: /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/jre/lib/i386 If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-Wl,--rpath -Wl,LIBDIR' linker flag - have your system administrator add LIBDIR to `/etc/ld.so.conf'See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. ---------------------------------------------------------------------- /usr/bin/install -c RXTXcomm.jar /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/jre/lib/ext/ /usr/bin/install: el destino, ?/usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/jre/lib/ext/?, no es un directorio: No existe el fichero ? directoriomake: *** [install] Error 1 This error its no important because its due to this fold doest exist and cant install RXTXcomm.jar but doesnt matter. Next i copy native libraries to classpath. I tested a simple app that only print the serial ports. The execution was ok but no serial ports were printed, i was using serial port to comunicate pc with NGW100 trough a terminal, but the output of the app was null, no serial ports were found. I dont know whats the problem, do i need some adittional resources? Thanks for your help! Pixu _________________________________________________________________ ?Qu?tate unos clics! Ahora, Internet Explorer 8 tiene todo lo que te gusta de Windows Live ?Cons?guelo gratis! http://ie8.msn.com/microsoft/internet-explorer-8/es-es/ie8.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090523/c4640863/attachment-0001.html From tjarvi at qbang.org Sat May 23 17:08:33 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 May 2009 17:08:33 -0600 (MDT) Subject: [Rxtx] porting rxtx to avr32-linux In-Reply-To: References: Message-ID: On Sat, 23 May 2009, Samuel Ovia?o Su?rez wrote: > Hi!, > > I think i achieve complete the porting. I followed the next steps: > > - At SerialImp.h , comment out line 441 > - At I2CImp.c , comment out lines 96 to 100 > - At RawImp.c , comment out lines 240 to 244 and line 65 > - At RS485Imp.c, comment out lines 96 to 100 > > Then i did make install and the output was the following: > > ---------------------------------------------------------------------- > > Libraries have been installed in: > > /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/jre/lib/i386 > > > If you ever happen to want to link against installed libraries > > in a given directory, LIBDIR, you must either use libtool, and > > specify the full pathname of the library, or use the `-LLIBDIR' > > flag during linking and do at least one of the following: > > - add LIBDIR to the `LD_LIBRARY_PATH' environment variable > > during execution > > - add LIBDIR to the `LD_RUN_PATH' environment variable > > during linking > > - use the `-Wl,--rpath -Wl,LIBDIR' linker flag > > - have your system administrator add LIBDIR to `/etc/ld.so.conf' > > See any operating system documentation about shared libraries for > > more information, such as the ld(1) and ld.so(8) manual pages. > > ---------------------------------------------------------------------- > > /usr/bin/install -c RXTXcomm.jar > /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/jre/lib/ext/ > > /usr/bin/install: el destino, > ?/usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/jre/lib/ext/?, no es un directorio: > No existe el fichero ? directorio > > make: *** [install] Error 1 > > > This error its no important because its due to this fold doest exist and > cant install RXTXcomm.jar but doesnt matter. > > Next i copy native libraries to classpath. > > I tested a simple app that only print the serial ports. The execution was ok > but no serial ports were printed, i was using serial port to comunicate pc > with NGW100 > trough a terminal, but the output of the app was null, no serial ports were > found. I dont know whats the problem, do i need some adittional resources? > > Thanks Pixu, Which libc and version did you compile against? -- Trent Jarvi tjarvi at qbang.org From pixue_breaker at hotmail.com Sun May 24 10:14:01 2009 From: pixue_breaker at hotmail.com (=?iso-8859-1?Q?Samuel_Ovia=F1o_Su=E1rez?=) Date: Sun, 24 May 2009 16:14:01 +0000 Subject: [Rxtx] porting rxtx to avr32-linux In-Reply-To: References: Message-ID: Hi, I use libc6 2.7-10Ubuntu4. > Thanks Pixu, > > Which libc and version did you compile against? > > -- > Trent Jarvi > tjarvi at qbang.org _________________________________________________________________ ?Acelera con la F?rmula 1! Juega y demuestra lo que sabes con MSN Deportes http://msn.es.predictorpro.com/grand-prix/overview.aspx?season=8 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090524/428ca14a/attachment.html From Steffen.DETTMER at ingenico.com Mon May 25 02:57:45 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 25 May 2009 10:57:45 +0200 Subject: [Rxtx] InputStream timeouts - opinions on breaking compatibility? In-Reply-To: References: <5D23E5B41156B646B2E1A7C2BBA916F317119151B6@SRVFIHKIEXB01.pmgroup.local> Message-ID: <20090525085745.GC18419@elberon.bln.de.ingenico.com> Hi, Kusti and Bob wrote almost exactly what I also feel :) * Bob Jacobsen wrote on Fri, May 22, 2009 at 09:05 -0700: > At 10:49 AM +0300 5/21/09, Kustaa Nyholm wrote: > >A month or so ago a lot of people chimed in by telling *what* > >they do with rxtx, now I would really be interesting to know > >*how* people are using rxtx? > > > >More specifically and relevant to this discussion: > > > >1) are timeouts used? Yes, they are used. As we run some protocols (often STX/ETX/LRC/ACK things), timeouts are essential to control retransmission, to resynchronize after heavy errors and in worst case to cancel / abort. Utilizing full serial bandwidth with `cable removal detection', error correction by retransmission etc. isn't that easy to implement and IMHO impossible without timeouts. In total (not rxtx related, but general for all communications) we had several issues with timeouts, for instance undesired retransmissions because of less precise timeouts or less carefully choosen values and `communication strategies' (protocols), mutual `clear-line-and-retransmit' endless loops (because of too symetric protocols), too slow communication even on small bit error rates. Timeouts errors on heavy loaded servers (our multiport cards were able to buffer a few bytes only, which seems to be common). > >2) how are they handled? > > Just repeat the read Our wrappers offer somewhat precise timeouts (better than 100ms, using timers, allowing very long timeouts if needed, too) in a comfortable way (intercharacter timeout support [not dependent of lower layer ic to], things line DEFAULT_MILISECS for easy usage). > >3) are SerialPort InputStreams passed to library functions? > > Yes. In our case the InputStreams of rxtx are not passed, but since often InputStreams are needed, we have such wrappers too (someone could say `wrapping it back', but of course usage semantics change a bit and the wrappers do a bit of work, too). This isn't considered very efficient, but performance isn't a big issue in case of serial links. Today 32 Modems come in a 19" chassis with Ethernet plug :-) > >4) have there been problems (in 3 above)? Yes, there were various issue, don't remember all. Common was that the assumptions made to InputStream were wrong. Sometimes polling avialable() quickly does not work well or a read takes a while even when a few bytes are read (because of some internal threshold or so) and applications may not expect this. Of course, other applications may depend on this (for instance, if they don't call read(byte[]) in a loop). An InputStream wrapper we have for instance is doing communication in its avialable method with configurable timeouts and big buffers (64 KB!). Sometimes InputStream is used in a way where the one or other communication strategy is more performant but the other is really wasting resources (sometimes it might be good not to actually read in read but just look at some buffer or whatever helps, this can be arbitrary complex). > >5) how would you feel if you would need to rework your code to work > >with the 'improved' API? > > If you changed the API? Very, very unhappy. Yes, especially as long as neither forcing reasons nor unquestionable final improvements :) > >The proposal we have (by Gili) is: > > > > > 1) add "CommPortChannel getChannel()" > > > 2) deprecate getInputStream() and enableReceiveTimeout() in favor of > > > getChannel() > > You should only deprecate something you intend to eventually > remove. What's the reason to _remove_ these? They do what > they do. Yes, and I think almost any Java guy is used to use InputStream stuff, so it is what people expect, I think. > > > 3) getChannel() will return a class that implements the > > > same interfaces as SocketChannel. It will allow both > > > blocking and non-blocking I/O operations. > > If this is going to be done, somebody should _first_ write a very > detailed API of what the SocketChannel interface "means" for serial > communications (which isn't just bytes and EOF). Yes, and show that it is possible to implement it that correct, that it is possible to use all its (SocketChannel) features just as it is for TCP and at the same time with other SocketChannel implementation. That means, it must be possible to select TCP and multiple serial ports at the same time, just as on un*x, because this is what SocketChannel is for and what people would expect. Finally, it should be possible to make an implementation with some usable performance on all supported platforms. For windows, this might be difficult. Cygwin implements select support in such a way but as far as I know this has impacts on performance (but still is very usable IMHO!). If internally some quick polling would be needed, I think it would not make much sense to implement it then. > > > 4) In RXTX 3.0 getInputStream() will return an InputStream > > > that always blocks on reads and the method will be > > > undeprecated. > > Very, very opposed to this. If you want to provide another > interface, fine, but don't hijack an existing one. This will result > in significant maintenance problems as people have to mix and match > various versions of RXTX for concurrent use. I agree. Also, this InputStream would be almost unusable if it does not support any timeouts I think. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From m.j.tandy at warwick.ac.uk Mon May 25 03:48:49 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Mon, 25 May 2009 10:48:49 +0100 Subject: [Rxtx] InputStream timeouts - opinions on breaking compatibility? In-Reply-To: <5D23E5B41156B646B2E1A7C2BBA916F317119151B6@SRVFIHKIEXB01.pmgroup.local> References: <5D23E5B41156B646B2E1A7C2BBA916F317119151B6@SRVFIHKIEXB01.pmgroup.local> Message-ID: <302aa0340905250248g741384e6w8d4031ae920914b2@mail.gmail.com> >> 4) In RXTX 3.0 getInputStream() will return an InputStream that always blocks >> on reads and the method will be undeprecated. Perhaps I'm missing something, but how would this be different from the current InputStream, if disableReceiveTimeout() has been used? From Kustaa.Nyholm at planmeca.com Mon May 25 04:06:21 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 25 May 2009 13:06:21 +0300 Subject: [Rxtx] InputStream timeouts - opinions on breaking compatibility? In-Reply-To: <302aa0340905250248g741384e6w8d4031ae920914b2@mail.gmail.com> Message-ID: >>> 4) In RXTX 3.0 getInputStream() will return an InputStream that always >>> blocks >>> on reads and the method will be undeprecated. > > Perhaps I'm missing something, but how would this be different from > the current InputStream, if disableReceiveTimeout() has been used? It would be just the same, but I suspect Gili's proposal would be calling for read() and read(byte[]) to wait for at least one char even with timeouts! cheers Kusti From Steffen.DETTMER at ingenico.com Mon May 25 04:08:03 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 25 May 2009 12:08:03 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A14164B.6040000@bbs.darktech.org> References: <4A131674.6000906@bbs.darktech.org> <20090520083008.GH17036@elberon.bln.de.ingenico.com> <4A13DDE3.8070703@bbs.darktech.org> <20090520132339.GB27170@elberon.bln.de.ingenico.com> <4A14164B.6040000@bbs.darktech.org> Message-ID: <20090525100803.GE18419@elberon.bln.de.ingenico.com> (OT) * cowwoc wrote on Wed, May 20, 2009 at 10:40 -0400: > Steffen DETTMER wrote: > >First, I disagree that it is specification because it actually is > >documentation. > > That is incorrect. Design by Contract [...] seems I'm unable to follow... Are you saying you consider the javadocs as design by contract spec? But the returning zero case, which is not explicitely forbidden as postcondition, wouldn't be affected anyway I think. > >Also, it often happens that even in specifications there are > >obvious issues, as soon as everyone does the obvious thing, > >instead of changing all implementations, the specification is > >fixed. Or left as it is :) > > As far as I know, this has never been done for core Java > classes because doing so would break backwards compatibility. If implementations differ from doc (spec) and code relies and that differences, fixing the doc (spec) is what is backward compatibile. > >Of course we define an own interface by deriving (implementing) > >InputStream because specifics will happen. For instance > >specialised exceptions may be thrown in special new situations > >not documented (specified) by InputStream. This is what OO is for > >I think. :) > > A subclass may not throw any new (checked) exceptions. Doing so > would violating the superclass specification. You could always > throw a subclass of IOException but that's about it. Yes, as I said, any new specialised IOException may be thrown without beeing documented. > The reason this only applies to checked exceptions is that all > methods throw RuntimeException by default. (which is a good example for pragmatism. The `checked exception' idea does not work to 100% so either we end up with `throws Exception', additional support of unchecked exceptions [like RuntimeException subclasses that store and `tunnel' exceptions to work around interface limitations] or both) > >Strictly speaking, at least for me with my limited foreign > >language English knowledge, it does not tell what happens if an > >attempt to read at least one byte was done, no byte was > >available, the stream is NOT at the end of the file, but still no > >byte was read. > > The sentence above reads "This method blocks until input data > is available, end of file is detected, or an exception is > thrown." In other words, you must block. Yes, /this method/ blocks, but overwritten may not block. BTW `or an exception is thrown' isn't very precise (who throws what when for whom why ;)). > If a timeout could be said to be a new kind of end-of-stream (with > the resulting behavior being absolutely identical) then using -1 might be > fine. Unfortunately, this is not the case. End-of-stream indicates that > the InputStream will never return bytes ever again. What if reset() is used? > Timeouts violate this guarantee. With respect to exceptions, > you are allowed to throw any subclass of IOException for the > reasons mentioned in Design by Contract. Yes, I agree. -1 is no option (and throwing isn't one either). > >>Fair enough, but "timeouts in a loop" -- using available() -- > >>don't break the InputStream specification. > > > >Yes, and somewhere probably there is some guy who defined > >InputStream as an Aprils Fool Joke and now cannot sleep because > >laughing about all those people that poll available() all the > >time (no delay to gain response time) wasting all CPU resources > >:-) > > InputStream works perfectly fine for synchronous reading. If > you want asynchronous reading you are supposed to use NIO > channels. InputStream IMHO does not work fine, because in practice timeouts are always needed except for command line tools. NIO supports asynchronous reading? i.e. filling a user buffer while no call is active (after return of a startRead or so)? > >>NIO allows you to select() on a channel with a timeout, which > >>is the point of contention. > >Yes, but not if the channel is some InputStream like STDIN, > >right? Also, as far as I know, you cannot select on own things. > >So wouldn't work for serial lines or protocols. > > I don't understand what you mean. You can get a Channel for > System.in using java.nio.channels.Channels. I meant, there is no InputStream.getChannel(). Of course not. This looks correct. But since this also does not make much sense and would be hard, there is a FileInputStream.getChannel(). So if some lib or whatever implements InputStream, no select is possible. But even FileInputStream.getChannel() doesn't help, because it is not a SelectableChannel so still no timeouts in file I/O, right? Interesting that System.in can be taken as SelectableChannel. Didn't know that. What must be called? Guess it has a `magic source' - how does it work? Some URL would be nice. Also worth noting IMHO is that for support of Channels and select many APIs had been modified (i.e. FileInputStream.getChannel() was added, but as far as I understood still isn't selectable). We'll see what happens if a `Channel' replacement/successor comes. Maybe then additionally FileInputStream.getChannelNew() or so will be available. SCNR. Anyway, I think it is visible that the old IO (InputStream) wasn't that good and a new IO had been added. Maybe because a java developer got a un*x system programming book. Well, some things like `Updates made to a file may be forced out to the underlying storage device, ensuring that data are not lost in the event of a system crash.' are still wrong but maybe it will be fixed in future. But Java IMHO isn't that formal that this plays a role. Most people understand what is meant. > >I think you cannot implement TCP via PPP reasonable and > >efficiently in (pure) Java, even with NIO as far as I know > >this is not possible. But there are many things in Java that > >you cannot implement in Java (even String!). > > You can find TCP/PPP implementations in Java on the web. You > don't need them most of the time because the OS provides an > implementation for free. Well, you gave no example link, so I still believe that you cannot implement TCP via PPP reasonable and efficiently in (pure) Java. NIO itself surely uses much native code. (also, you cannot implement TCP/PPP on un*x supporting /the/ POSIX APIs, i.e. making select(2) working on user defined file descriptors / buffers). > > >I think, when we would discuss NIO, we would also quickly find > >sufficient issues with it (I think we had this discussion > >already) and that we do not (really :)) break the superclass > >contract (of InputStream). We just add possibility to support > >timeout (by new method setReceiveTimeout() and overloaded read()). > > Again, I suggest you read up on Design by Contract. You will > find out exactly why you are not allowed to overload the -1 > return code in this way. The -1 return code is for a different case, EOF, and remains unchanged: if no timeout but EOF, -1 is returned, as specified. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Mon May 25 04:18:16 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 25 May 2009 13:18:16 +0300 Subject: [Rxtx] More YAK on design purity... Message-ID: Hi, just realized that SerialPort.getInputStream() javadoc says: "This is the only way to receive data from the communications port" So if we are to take javadoc as specification and if we are concerned that the specification should be strictly adhered to then we should not be add any (getInputChannel) methods to Serial port that allows reception of data! Ok, that was just teasing, but seriously, I'm not opposed to adding getInputChannel() but would first like to see and scrutinize a sample implementation before we pollute SerialPort. If the cure is worse than the disease we should just bear it not cure it. cheers Kusti From Steffen.DETTMER at ingenico.com Mon May 25 04:28:24 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 25 May 2009 12:28:24 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: <5D23E5B41156B646B2E1A7C2BBA916F317119151B5@SRVFIHKIEXB01.pmgroup.local> References: <5D23E5B41156B646B2E1A7C2BBA916F317119151B5@SRVFIHKIEXB01.pmgroup.local> Message-ID: <20090525102823.GF18419@elberon.bln.de.ingenico.com> (OT) * Kustaa Nyholm wrote on Thu, May 21, 2009 at 10:20 +0300: > * Gili wrote: > > Right now you cannot safely pass RXTX's InputStream into any > > other library in existence. > > Now that is blatantly untrue. If timeouts are not enable you can pass > it safely to any library. But how should a GUI display a timeout error then? I know that almost any software is broken regarding `situations that do not happen', for example, if reading a config file blocks, most GUIs probably will block, often this is sufficient, but on serial and other network communications timeouts may happen and thus IMHO applications should not rely on the arival of data. Well, as for many oversimplified designs multi-threading may help (for the cost of a very complex, almost untestable design :)). So I think InputStream should be passed to lib functions only with enabled (maybe very long) timeouts. Usually they should be protocols but this is another topic :-) > When timeouts are enabled *some* libraries will > not work, some will. > > If you worry or encounter such a situation you can then do some > wrapper magic. But for pete's sake, let us not disturb the > happy life of rxtx users with well intentioned but misguided > zealozy. > > I wonder too how often SerialPort input stream is passed to *any* library? > > I certainly haven't done that ever. > Yes, I agree to all those points... I think, many libraries do not tolerate reading any garbage and so not support timeouts etc, which IMHO means that those should be implemented in InputStream classes, but whatever is choosen, it won't be safe (reliable). Which of course also depends on the requirements (someone may want to abort everything on a read error, others may retry or ignore a bunch of data). > The way I vision people are using serial port is to talk > directly to it doing most if not all of the protocol handling > with custom code, not with a library. Yeah... When for instance someone would like to run SSL on serial link (which is not possible with Java SSL AFAIK thanks to its bad API ;)), it would be broken by design, because SSL requires a reliable link and serial links aren't, BUT maybe it is a `virtual COM port'? Or maybe compelete (SSL session) abort is acceptable or desired in case of a bit error (like a paranoid super hyper link protection). So maybe there is case where it makes sense. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Mon May 25 05:15:48 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 25 May 2009 14:15:48 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090525102823.GF18419@elberon.bln.de.ingenico.com> Message-ID: > >> Now that is blatantly untrue. If timeouts are not enable you can pass >> it safely to any library. > > But how should a GUI display a timeout error then? I know that > almost any software is broken regarding `situations that do not > happen', for example, if reading a config file blocks, most GUIs > probably will block, often this is sufficient, but on serial and > other network communications timeouts may happen and thus IMHO > applications should not rely on the arival of data. Well, as for > many oversimplified designs multi-threading may help (for the > cost of a very complex, almost untestable design :)). Yes, you are right about that, but I was merely commenting on the sweeping statement that Gili made saying that one cannot pass InputStream to *any other library in existence*. cheers Kusti From lyon at docjava.com Mon May 25 06:04:40 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 25 May 2009 08:04:40 -0400 Subject: [Rxtx] sole of a new api In-Reply-To: References: Message-ID: Hi All, I am about to embark on a new API for video capture. The goal is to capture video on 64bit Java 6 capable macs. The plan is to use JNA. Is anyone else working on this? Thanks! - Doug From cowwoc at bbs.darktech.org Mon May 25 06:48:17 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Mon, 25 May 2009 08:48:17 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090525100803.GE18419@elberon.bln.de.ingenico.com> References: <4A131674.6000906@bbs.darktech.org> <20090520083008.GH17036@elberon.bln.de.ingenico.com> <4A13DDE3.8070703@bbs.darktech.org> <20090520132339.GB27170@elberon.bln.de.ingenico.com> <4A14164B.6040000@bbs.darktech.org> <20090525100803.GE18419@elberon.bln.de.ingenico.com> Message-ID: <4A1A9391.2000609@bbs.darktech.org> Steffen DETTMER wrote: >> That is incorrect. Design by Contract [...] > > seems I'm unable to follow... Are you saying you consider the > javadocs as design by contract spec? > But the returning zero case, which is not explicitely > forbidden as postcondition, wouldn't be affected anyway I think. Sure it is. The Javadoc for read() indicate that at least one byte will be read. If zero is returned it means that a data having a value equal to zero was read. The Javadoc for read(byte[]) say that at least one byte will be read, zero may only be returned if the input buffer had a size of zero. > If implementations differ from doc (spec) and code relies and > that differences, fixing the doc (spec) is what is backward > compatibile. You can't do that. There are already thousands of different InputStream implementations in the wild that depend on the existing specification. >> The sentence above reads "This method blocks until input data >> is available, end of file is detected, or an exception is >> thrown." In other words, you must block. > > Yes, /this method/ blocks, but overwritten may not block. > BTW `or an exception is thrown' isn't very precise (who throws > what when for whom why ;)). As discussed, Design by Contract states that subclasses must adhere to the contract of the superclass. If the superclass blocks for a particular input, the subclass must do the same. With respect to "an exception is thrown" the actual list of exceptions is listed right below. >> If a timeout could be said to be a new kind of end-of-stream (with >> the resulting behavior being absolutely identical) then using -1 might be >> fine. Unfortunately, this is not the case. End-of-stream indicates that >> the InputStream will never return bytes ever again. > > What if reset() is used? Good question. In this case I'm guessing that the InputStream is reset prior to the end-of-stream. That being said, I think there is a difference between jumping back in a linear stream (that must always terminate on the same position) versus returning -1 for a timeout, then the next read() might not return -1 anymore and the "end of stream" position keeps on moving forward. The "end" being returned by RXTX is a false positive in this case. > InputStream IMHO does not work fine, because in practice timeouts > are always needed except for command line tools. Fair enough, but then we shouldn't be using it at all. It was probably used for historical reasons before NIO existed but we can do better now. > NIO supports asynchronous reading? i.e. filling a user buffer > while no call is active (after return of a startRead or so)? Yes. >>>> NIO allows you to select() on a channel with a timeout, which >>>> is the point of contention. >>> Yes, but not if the channel is some InputStream like STDIN, >>> right? Also, as far as I know, you cannot select on own things. >>> So wouldn't work for serial lines or protocols. >> I don't understand what you mean. You can get a Channel for >> System.in using java.nio.channels.Channels. > > I meant, there is no InputStream.getChannel(). Of course not. > This looks correct. But since this also does not make much sense > and would be hard, there is a FileInputStream.getChannel(). > So if some lib or whatever implements InputStream, no select is > possible. But even FileInputStream.getChannel() doesn't help, > because it is not a SelectableChannel so still no timeouts in > file I/O, right? Right. > Interesting that System.in can be taken as SelectableChannel. > Didn't know that. What must be called? Getting a channel for System.in doesn't necessarily mean it's Selectable (in fact, it's not). > Also worth noting IMHO is that for support of Channels and select > many APIs had been modified (i.e. FileInputStream.getChannel() > was added, but as far as I understood still isn't selectable). > We'll see what happens if a `Channel' replacement/successor > comes. Maybe then additionally FileInputStream.getChannelNew() or > so will be available. SCNR. Here you go: http://download.java.net/jdk7/docs/api/java/nio/channels/AsynchronousChannel.html NIO2 (due in JDK7) will not be replacing Channel but rather extending it to allow asynchronous I/O as opposed to a polled non-blocking I/O. The functionality is identical, it is just more efficient. It is worth noting that the transition from InputStream to Channel is not the same as the latter provides substantially more functionality than the former. Gili From luis.moreira at ntlworld.com Sat May 2 00:39:04 2009 From: luis.moreira at ntlworld.com (luis.moreira at ntlworld.com) Date: Sat, 2 May 2009 7:39:04 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Hi Travis, The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. The issues I still have is the errors after that. Do you have any idea what can be causing this errors? _______________________________________________________________________________ conftest.c: In function 'main': conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) conftest.c:8: error: (Each undeclared identifier is reported only once conftest.c:8: error: for each function it appears in.) conftest.c:8: error: expected ')' before string constant conftest.c:8: warning: format not a string literal and no format arguments ./configure: line 21462: ./conftest: No such file or directory ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands ------------------------------------------------------------------------------- I don't know what happened to my previous post, it as not showed up in the list. Best Regards Luis From tjarvi at qbang.org Sat May 2 07:30:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 07:30:04 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> References: <20090502073904.4X27O.883595.root@web06-winn.ispmail.private.ntl.com> Message-ID: On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > Hi Travis, > The problem with the Makefile is not a problem,When I run ./configure I make a new Makefile with the same data in it, hence what I just modified is removed. > The issues I still have is the errors after that. Do you have any idea what can be causing this errors? > > _______________________________________________________________________________ > conftest.c: In function 'main': > conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this function) > conftest.c:8: error: (Each undeclared identifier is reported only once > conftest.c:8: error: for each function it appears in.) > conftest.c:8: error: expected ')' before string constant > conftest.c:8: warning: format not a string literal and no format arguments > ./configure: line 21462: ./conftest: No such file or directory > ./configure: line 21462: test: 2.6.28-11-generic: unary operator expected > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: config.h is unchanged > config.status: executing depfiles commands > ------------------------------------------------------------------------------- > > This was corrected in CVS. I think you can just do the following in the top directory: cvs login: (pw is mousy) cvs update That will get the current fixes. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sat May 2 16:14:50 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sat, 02 May 2009 23:14:50 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FCC5DA.6000700@ntlworld.com> Trent Jarvi wrote: > > > On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: > >> Hi Travis, >> The problem with the Makefile is not a problem,When I run ./configure >> I make a new Makefile with the same data in it, hence what I just >> modified is removed. >> The issues I still have is the errors after that. Do you have any >> idea what can be causing this errors? >> >> _______________________________________________________________________________ >> >> conftest.c: In function 'main': >> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >> function) >> conftest.c:8: error: (Each undeclared identifier is reported only once >> conftest.c:8: error: for each function it appears in.) >> conftest.c:8: error: expected ')' before string constant >> conftest.c:8: warning: format not a string literal and no format >> arguments >> ./configure: line 21462: ./conftest: No such file or directory >> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >> expected >> configure: creating ./config.status >> config.status: creating Makefile >> config.status: creating config.h >> config.status: config.h is unchanged >> config.status: executing depfiles commands >> ------------------------------------------------------------------------------- >> >> >> > > This was corrected in CVS. I think you can just do the following in > the top directory: > > cvs login: (pw is mousy) > cvs update > > That will get the current fixes. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, apologies for the mix-up of your name. I managed to get further on by updating CVS, the configure command gets to the end without any errors, it still warns me that it is confused about where to find the jni_md.h but I just edited the Makefile and sorted that out. I then run make, with no parameters following the instructions on the Wiki, but that generated a few more errors: ----------------------------------------------------------------------------------------------------------------------- gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. -I/usr/lib/jvm/java-6-openjdk/include /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -c /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' undeclared (first use in this function) /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared identifier is reported only once /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each function it appears in.) libtool: link: `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 ----------------------------------------------------------------------------------------------------------------------- Another question I have is, in which folder will the .so files be placed after make finishes? thank you very much for your help. Best Regards Luis From tjarvi at qbang.org Sat May 2 19:27:08 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 2 May 2009 19:27:08 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FCC5DA.6000700@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> Message-ID: On Sat, 2 May 2009, Luis Moreira wrote: > Trent Jarvi wrote: >> >> >> On Sat, 2 May 2009, luis.moreira at ntlworld.com wrote: >> >>> Hi Travis, >>> The problem with the Makefile is not a problem,When I run ./configure >>> I make a new Makefile with the same data in it, hence what I just >>> modified is removed. >>> The issues I still have is the errors after that. Do you have any >>> idea what can be causing this errors? >>> >>> _______________________________________________________________________________ >>> >>> conftest.c: In function 'main': >>> conftest.c:8: error: 'UTS_RELEASE' undeclared (first use in this >>> function) >>> conftest.c:8: error: (Each undeclared identifier is reported only once >>> conftest.c:8: error: for each function it appears in.) >>> conftest.c:8: error: expected ')' before string constant >>> conftest.c:8: warning: format not a string literal and no format >>> arguments >>> ./configure: line 21462: ./conftest: No such file or directory >>> ./configure: line 21462: test: 2.6.28-11-generic: unary operator >>> expected >>> configure: creating ./config.status >>> config.status: creating Makefile >>> config.status: creating config.h >>> config.status: config.h is unchanged >>> config.status: executing depfiles commands >>> ------------------------------------------------------------------------------- >>> >>> >>> >> >> This was corrected in CVS. I think you can just do the following in >> the top directory: >> >> cvs login: (pw is mousy) >> cvs update >> >> That will get the current fixes. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > apologies for the mix-up of your name. > I managed to get further on by updating CVS, the configure command gets > to the end without any errors, it still warns me that it is confused > about where to find the jni_md.h but I just edited the Makefile and > sorted that out. > I then run make, with no parameters following the instructions on the > Wiki, but that generated a few more errors: > ----------------------------------------------------------------------------------------------------------------------- > > gcc -I/home/luis/RxTx/rxtx-2.1-7r2 -Ii686-pc-linux-gnu -I. > -I/usr/lib/jvm/java-6-openjdk/include > /usr/lib/jvm/java-6-openjdk/include/linux -g -O2 -D_POSIX_SOURCE > -D_BSD_SOURCE -D__need_timespec -c > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c -fPIC -DPIC -o > /home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: 'UTS_RELEASE' > undeclared (first use in this function) > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: (Each undeclared > identifier is reported only once > /home/luis/RxTx/rxtx-2.1-7r2/./src/I2CImp.c:135: error: for each > function it appears in.) > libtool: link: > `/home/luis/RxTx/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a > valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Error 1 > ----------------------------------------------------------------------------------------------------------------------- > > Another question I have is, in which folder will the .so files be placed > after make finishes? > > thank you very much for your help. > Ah when you do cvs update pass the -Pd option cvs update -Pd Also, when you run configure, use --disable-PRINTER to only build the serial support. It will make things easier. --disable-LOCKFILES will also be easier to get going until you want to learn about how to prevent multiple applications from reading the same serial port. The link for debugging will describe where the files go. By default, it will install in the JRE/JDK under jre/lib/ext (the jar file) jre/lib/i386 (the .so file) Those are on the proper paths when you use the sun or ibm jdk. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Sun May 3 01:30:43 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Sun, 03 May 2009 08:30:43 +0100 Subject: [Rxtx] First use of RXTX package In-Reply-To: References: <49FCC5DA.6000700@ntlworld.com> Message-ID: <49FD4823.5080204@ntlworld.com> Ah > > when you do cvs update pass the -Pd option > > cvs update -Pd > > Also, when you run configure, use --disable-PRINTER to only build the > serial support. It will make things easier. --disable-LOCKFILES will > also be easier to get going until you want to learn about how to > prevent multiple applications from reading the same serial port. > > The link for debugging will describe where the files go. By default, > it will install in the JRE/JDK under > > jre/lib/ext (the jar file) > jre/lib/i386 (the .so file) > > Those are on the proper paths when you use the sun or ibm jdk. > > http://rxtx.qbang.org/wiki/index.php/Trouble_shooting > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, It as done it! I think this instructions you gave me should be on the Wiki, I can write them for you if you like. Also on the Wiki when you describe the three methods of installing the RxTx package it is confusing because as far as I can see, you always have to do method 1 or the .so files will not be generated(is this correct?). Then you can if you like change the location with method 1 & 2. Is it possible to modify the .la file to point to different directories for installation and then you can decide where to place the files? In a way I have learned quite a lot about Linux by having to struggle, with your help, to find solutions to the problems I encountered (I am still very new to Linux), but maybe we need to log these problems somewhere to make it less of a struggle for others like me. I have used the PortLister example to test it and it came up with my USB to dual Serial adaptor Ports. I will now explore the RxTx package, before I tackle the windows installation, I will let you know of my experience. Thank you for all your Help. Best Regards Luis From tjarvi at qbang.org Sun May 3 10:37:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 3 May 2009 10:37:50 -0600 (MDT) Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FD4823.5080204@ntlworld.com> References: <49FCC5DA.6000700@ntlworld.com> <49FD4823.5080204@ntlworld.com> Message-ID: On Sun, 3 May 2009, Luis Moreira wrote: > Ah >> >> when you do cvs update pass the -Pd option >> >> cvs update -Pd >> >> Also, when you run configure, use --disable-PRINTER to only build the >> serial support. It will make things easier. --disable-LOCKFILES will >> also be easier to get going until you want to learn about how to >> prevent multiple applications from reading the same serial port. >> >> The link for debugging will describe where the files go. By default, >> it will install in the JRE/JDK under >> >> jre/lib/ext (the jar file) >> jre/lib/i386 (the .so file) >> >> Those are on the proper paths when you use the sun or ibm jdk. >> >> http://rxtx.qbang.org/wiki/index.php/Trouble_shooting >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > Hi Trent, > It as done it! > I think this instructions you gave me should be on the Wiki, I can write > them for you if you like. Also on the Wiki when you describe the three > methods of installing the RxTx package it is confusing because as far > as I can see, you always have to do method 1 or the .so files will not > be generated(is this correct?). Then you can if you like change the > location with method 1 & 2. Is it possible to modify the .la file to > point to different directories for installation and then you can decide > where to place the files? > In a way I have learned quite a lot about Linux by having to struggle, > with your help, to find solutions to the problems I encountered (I am > still very new to Linux), but maybe we need to log these problems > somewhere to make it less of a struggle for others like me. > > I have used the PortLister example to test it and it came up with my USB > to dual Serial adaptor Ports. > > I will now explore the RxTx package, before I tackle the windows > installation, I will let you know of my experience. > > Thank you for all your Help. > Hi Luis, The locations suggested for first time configuration could be documented in a new wiki page explaining that this is not the recommended general workflow but does help new users that are not worried about having rxtx installed into the JRE. For a professional environment, the user would want to follow the workflow currently on the wiki and keep their JRE clean. Often the user will not be able to add libraries to the JRE and will need to use their home directory or a sandbox. Feel free to add information to the wiki. I'd suggest creating comment in the current page and have the comment link to what worked for you as a first time user new to Linux. You can create a new page with your comments. In the long term, we will be working on an autoinstaller that works over the web. -- Trent Jarvi tjarvi at qbang.org From luis.moreira at ntlworld.com Mon May 4 09:15:40 2009 From: luis.moreira at ntlworld.com (Luis Moreira) Date: Mon, 04 May 2009 16:15:40 +0100 Subject: [Rxtx] First use of RXTX package Message-ID: <49FF069C.8040406@ntlworld.com> Hi Trent, I have now installed the package on my 64 bit machine and when I run my program I get errors on the attachment. I know it as something to do with the architecture of my system but I can no figure out how to fix it. I have built it from source again, I did not transfer the files from machine to machine. can you please put me in the right direction. Thank you very much for your help. Best Regards Luis -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshoot.png Type: image/png Size: 25753 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090504/141ab5dc/attachment-0022.png From johnny.luong at trustcommerce.com Mon May 4 11:57:08 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 04 May 2009 10:57:08 -0700 Subject: [Rxtx] First use of RXTX package In-Reply-To: <49FF069C.8040406@ntlworld.com> References: <49FF069C.8040406@ntlworld.com> Message-ID: <49FF2C74.90805@trustcommerce.com> Luis Moreira wrote: > Hi Trent, > I have now installed the package on my 64 bit machine and when I run my > program I get errors on the attachment. I know it as something to do > with the architecture of my system but I can no figure out how to fix > it. I have built it from source again, I did not transfer the files from > machine to machine. > can you please put me in the right direction. > Thank you very much for your help. > Best Regards > Luis > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Hi, Does running it on a 64-bit JVM help? Your host environment might be building objects for a 64-bit environment unless you did a cross-compile... -- you can find out by doing something like the following: johnny at spike:~$ java -version java version "1.6.0_0" OpenJDK Runtime Environment (build 1.6.0_0-b11) OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode) johnny at spike:~$ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) -Johnny From huangdongkai at gmail.com Wed May 6 11:06:06 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 01:06:06 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. Message-ID: Dear all, I recompile the rxtxSerial source code by MinGW32 and compile success. But when I run my Application which use rxtxSerial.dll to communicate with serial port, a runtime exception happened and application crash. I have no idea why it can not work, beacuse i have not change any source code of rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I have missed when compile the source code on Window NT? Here below is the output error massage. # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, tid=1360 # # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing windows-x86) # Problematic frame: # V [jvm.dll+0x1b6824] # # An error report file with more information is saved as: # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/32c1e699/attachment-0020.html From tjarvi at qbang.org Wed May 6 20:04:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 May 2009 20:04:10 -0600 (MDT) Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: On Thu, 7 May 2009, dongkai huang wrote: > Dear all, > ????? I recompile the rxtxSerial source code by MinGW32 and compile success. > But when I run my Application which use rxtxSerial.dll to communicate with > serial port, a runtime exception happened and application crash.? I have no > idea why it can not work, beacuse i have not change any source code of > rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing I > have missed when compile the source code on Window NT? Here below is the > output error massage. > # > # An unexpected error has been detected by Java Runtime Environment: > # > #? EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, > tid=1360 > # > # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing > windows-x86) > > # Problematic frame: > # V? [jvm.dll+0x1b6824] > # > # An error report file with more information is saved as: > # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log > # > # If you would like to submit a bug report, please visit: > #?? http://java.sun.com/webapps/bugreport/crash.jsp > # > > > Hi Dongkai Could you explain how you compiled rxtx with mingw? Did you run configure? Was the compiler native or a cross compiler (like compiling on Linux for Windows)? Is the crash happening when you first open the port or is it happening randomly later on? -- Trent Jarvi tjarvi at qbang.org From huangdongkai at gmail.com Wed May 6 20:48:56 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Thu, 7 May 2009 10:48:56 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Hi Trent, I was followed the step on INSTALL file, did not run the configure, I used the Makefile.mingw32 which include on the source code package, and only change some path( jdk home path etc.). And I use the native compiler on Windows. The crash happened on I call the getPortIdentifiers() every time. On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Dear all, >> I recompile the rxtxSerial source code by MinGW32 and compile >> success. >> But when I run my Application which use rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and application crash. I have >> no >> idea why it can not work, beacuse i have not change any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source code. Did some thing >> I >> have missed when compile the source code on Window NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is saved as: >> # D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> > Hi Dongkai > > Could you explain how you compiled rxtx with mingw? Did you run configure? > Was the compiler native or a cross compiler (like compiling on Linux for > Windows)? > > Is the crash happening when you first open the port or is it happening > randomly later on? > > -- > Trent Jarvi > tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/733eded5/attachment-0020.html From m.j.tandy at warwick.ac.uk Thu May 7 10:39:12 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 7 May 2009 17:39:12 +0100 Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. Message-ID: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> I've encountered a bug in how XON/XOFF are handled on Windows. The symptoms were: 1. XON/XOFF from device to PC did not stop transmission. 2. XON/XOFF characters were present in data read from serial port input stream, when it was expected that they would be stripped out. 3. Investigation with SysInternals PortMon revealed the following configuration when using rxtx: 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 while HyperTerminal, which did not have the same problems as me, produced the following: 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 In other words, the problem is that, in addition to being told to use XON/XOFF flow control, the computer has to explicitly be told which characters to use for 'XON' and 'XOFF'. This part of the configuration was being missed out. I got the latest rxtx source from CVS, and identified the problem as an omission in the 'init_termios' function of 'termios.c', which configures the unix/termios 'c_cc' (control characters) data structure - but omits to configure the VSTART and VSTOP control characters. Later, the termios c_cc data structure is translated (by termios_to_DCB) into a data structure named 'DCB', which is passed to the windows serial port configuration interface. By adding two lines defining the standard XON/XOFF characters to the function init_termios, the bug is fixed. A patch doing this is attached. Thanks, Michael Tandy -------------- next part -------------- A non-text attachment was scrubbed... Name: xon-xoff.diff Type: application/octet-stream Size: 667 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090507/159c0dcc/attachment-0019.obj From tjarvi at qbang.org Thu May 7 17:57:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 May 2009 17:57:28 -0600 (MDT) Subject: [Rxtx] XON/XOFF on Windows XP - bug and patch. In-Reply-To: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> References: <302aa0340905070939j927f8b7scfb0c10aff517c6d@mail.gmail.com> Message-ID: On Thu, 7 May 2009, Michael Tandy wrote: > I've encountered a bug in how XON/XOFF are handled on Windows. > > The symptoms were: > 1. XON/XOFF from device to PC did not stop transmission. > 2. XON/XOFF characters were present in data read from serial port > input stream, when it was expected that they would be stripped out. > 3. Investigation with SysInternals PortMon revealed the following > configuration when using rxtx: > > 23 0.00000307 java.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:4 ERR:0 > BRK:0 EVT:a XON:0 XOFF:0 > > while HyperTerminal, which did not have the same problems as me, > produced the following: > > 17 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 > > In other words, the problem is that, in addition to being told to use > XON/XOFF flow control, the computer has to explicitly be told which > characters to use for 'XON' and 'XOFF'. This part of the configuration > was being missed out. > > I got the latest rxtx source from CVS, and identified the problem as > an omission in the 'init_termios' function of 'termios.c', which > configures the unix/termios 'c_cc' (control characters) data structure > - but omits to configure the VSTART and VSTOP control characters. > Later, the termios c_cc data structure is translated (by > termios_to_DCB) into a data structure named 'DCB', which is passed to > the windows serial port configuration interface. > > By adding two lines defining the standard XON/XOFF characters to the > function init_termios, the bug is fixed. A patch doing this is > attached. > Thanks Michael, Good timing. I plan on releasing rxtx-2.2 this coming Sunday. -- Trent Jarvi tjarvi at qbang.org From wjr at weru.ksu.edu Fri May 8 11:38:29 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Fri, 08 May 2009 12:38:29 -0500 Subject: [Rxtx] swing jfilechooser lockup Message-ID: <4A046E15.6010907@weru.ksu.edu> Hi, I wrote a small swing app to download images from an industrial camera. I used the two way serial sample code as a starting point. The app works fine EXCEPT for a call to jfilechooser. After I open the comm port and then try to change the output directory or log file, the jfilechooser winds up trying to unpark (note, parking is not something I'm really familiar with) and doesn't. If I try to change the file or directory before I start the comm port, it works. If I click on menu items that don't call jfilechooser, everything is OK. If I try closing the comm port and then try to create a jfilechooser, it locks up. There is obviously some sort of deadlock here because the awt thread starts waiting on something but it's not clear what. I haven't gone thru the rxtx code yet because it's not in the file structure that netbeans wants for debugging purposes. However, debugging code that I don't have a clear idea of what it is supposed to do is not my idea of a good time. Does anyone have any ideas on what is going on here? Thanks, wjr From Bob_Jacobsen at lbl.gov Fri May 8 14:48:25 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Fri, 8 May 2009 13:48:25 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A046E15.6010907@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> Message-ID: At 12:38 PM -0500 5/8/09, Bill Rust wrote: >Hi, > >I wrote a small swing app to download images from an industrial camera. >I used the two way serial sample code as a starting point. The app works >fine EXCEPT for a call to jfilechooser. After I open the comm port and >then try to change the output directory or log file, the jfilechooser >winds up trying to unpark (note, parking is not something I'm really >familiar with) and doesn't. If I try to change the file or directory >before I start the comm port, it works. If I click on menu items that >don't call jfilechooser, everything is OK. If I try closing the comm >port and then try to create a jfilechooser, it locks up. There is >obviously some sort of deadlock here because the awt thread starts >waiting on something but it's not clear what. I haven't gone thru the >rxtx code yet because it's not in the file structure that netbeans wants >for debugging purposes. However, debugging code that I don't have a >clear idea of what it is supposed to do is not my idea of a good time. What is the threading structure of your code? The various high-function Swing components, such as JFileChooser, are notorious for doing Really Bad Stuff when invoked from off the Swing thread. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From bschlining at gmail.com Fri May 8 15:08:50 2009 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 8 May 2009 14:08:50 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: Bob's probably right...take look at javax.swing.SwingUtilites for the workaround to get your swing stuff invoked on the EventDispatchThread (EDT). Some swing-methods do work when called outside of the EDT, but just to be safe, do your creation and swing calls on the EDT. It's really simple, here's an example of a synchronous call. // Here's how to run stuff on the EDT from a different thread SwingUtilities.invokeAndWait(new Runnable() { public void run() { JFileChooser fc; // create, setup, show your filechooser // Get the result from the filechooser } }); To do a asynchronous call use SwingUtilities.invokeLater > >I wrote a small swing app to download images from an industrial camera. > >I used the two way serial sample code as a starting point. The app works > >fine EXCEPT for a call to jfilechooser. After I open the comm port and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090508/c21c2127/attachment-0018.html From tod at todbot.com Fri May 8 16:27:12 2009 From: tod at todbot.com (Tod E. Kurt) Date: Fri, 8 May 2009 15:27:12 -0700 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: References: <4A046E15.6010907@weru.ksu.edu> Message-ID: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> This is the exact technique I use to let the user choose which serial port to use on startup. Here's a method I've got in many of my sketches: void choosePort() { String portlist[] = Serial.list(); String port = null; javax.swing.SwingUtilities.invokeLater(new Runnable() { public void run() { try { String port = (String) javax.swing.JOptionPane.showInputDialog( null, "Select Serial Port", "MySuperSketch", javax.swing.JOptionPane.QUESTION_MESSAGE, null, portlist, null); if( port == null ) { javax.swing.JOptionPane.showMessageDialog(null, "No port chosen, goodbye"); System.exit(1); } serialPort = port; } catch (Exception e) { e.printStackTrace(); } } } ); } On May 8, 2009, at 2:08 p, Brian Schlining wrote: > Bob's probably right...take look at javax.swing.SwingUtilites for > the workaround to get your swing stuff invoked on the > EventDispatchThread (EDT). Some swing-methods do work when called > outside of the EDT, but just to be safe, do your creation and swing > calls on the EDT. It's really simple, here's an example of a > synchronous call. > > // Here's how to run stuff on the EDT from a different thread > SwingUtilities.invokeAndWait(new Runnable() { > public void run() { > JFileChooser fc; // create, setup, show your filechooser > // Get the result from the filechooser > } > }); > > To do a asynchronous call use SwingUtilities.invokeLater > > > >I wrote a small swing app to download images from an industrial > camera. > >I used the two way serial sample code as a starting point. The app > works > >fine EXCEPT for a call to jfilechooser. After I open the comm port > and > >then try to change the output directory or log file, the jfilechooser > >winds up trying to unpark (note, parking is not something I'm really > >familiar with) and doesn't. > What is the threading structure of your code? > > The various high-function Swing components, such as JFileChooser, are > notorious for doing Really Bad Stuff when invoked from off the Swing > thread. > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From huangdongkai at gmail.com Sat May 9 04:46:22 2009 From: huangdongkai at gmail.com (dongkai huang) Date: Sat, 9 May 2009 18:46:22 +0800 Subject: [Rxtx] Recompile RxtxSerial by MinGW32 cause a runtime exception when running application. In-Reply-To: References: Message-ID: Dear Trent, After I intsall the ming32-cross compile to compile the rxtxSerial.dll and testing, i found the same problem still exist. I am not sure my compiler version is the same as your's. Could you tell me the way you can success compile rxtx-2.1-7r2 release source code? Thanks for you kindly help. On Fri, May 8, 2009 at 8:04 AM, Trent Jarvi wrote: > > > On Thu, 7 May 2009, dongkai huang wrote: > > Hi Trent, >> The attach is the Make file I use to compile the rxtx. >> >> On Thu, May 7, 2009 at 10:48 AM, dongkai huang >> wrote: >> Hi Trent, >> I was followed the step on INSTALL file, did not run the >> configure, I used the Makefile.mingw32 which include on the >> source code package, and only change some path( jdk home path >> etc.). And I use the native compiler on Windows. >> The crash happened on I call the getPortIdentifiers() >> every time. >> >> On Thu, May 7, 2009 at 10:04 AM, Trent Jarvi wrote: >> >> >> On Thu, 7 May 2009, dongkai huang wrote: >> >> Dear all, >> I recompile the rxtxSerial source code by >> MinGW32 and compile success. >> But when I run my Application which use >> rxtxSerial.dll to communicate with >> serial port, a runtime exception happened and >> application crash. I have no >> idea why it can not work, beacuse i have not change >> any source code of >> rxtxSerial library. I am use the rxtx-2.1-7r2 source >> code. Did some thing I >> have missed when compile the source code on Window >> NT? Here below is the >> output error massage. >> # >> # An unexpected error has been detected by Java >> Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at >> pc=0x6da66824, pid=3504, >> tid=1360 >> # >> # Java VM: Java HotSpot(TM) Client VM (11.3-b02 >> mixed mode, sharing >> windows-x86) >> >> # Problematic frame: >> # V [jvm.dll+0x1b6824] >> # >> # An error report file with more information is >> saved as: >> # >> D:\project\FactoryDownload-USB-3_x\hs_err_pid3504.log >> # >> # If you would like to submit a bug report, please >> visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> >> >> >> Hi Dongkai >> >> Could you explain how you compiled rxtx with mingw? Did you run >> configure? Was the compiler native or a cross compiler (like >> compiling on Linux for Windows)? >> >> Is the crash happening when you first open the port or is it >> happening randomly later on? >> >> > Thanks Dongkai > > I'll look at your Makefile tomorrow. Which version of mingw was this? > > I suspect there is a problem with that makefile. I usually built that > version of rxtx for windows with a mingw32 cross compiler using the > configure script. > > The configure script may well work for you if you have a cygwin environment > with mingw instead of gcc. I'll take a look at what is different. > > -- > > Trent Jarvi > tjarvi at qbang.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090509/b729c429/attachment-0018.html From wjr at weru.ksu.edu Wed May 13 15:50:30 2009 From: wjr at weru.ksu.edu (Bill Rust) Date: Wed, 13 May 2009 16:50:30 -0500 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> Message-ID: <4A0B40A6.5070204@weru.ksu.edu> Tod's solution misses the point. He is picking and opening the serial port. That's the step before where my problem occurs. To recap: 1. I have a simple java swing app. 2. On the menu bar, there is the standard set, file, etc., of jmenu's. Under file, there is a jmenuitem, logfileopen, which pops up a jfilechooser to select a logfile and another jmenuitem, setprefix, which pops up a jdialog to allow the user to type in a file name prefix for downloaded images. 3. There is another jmenuitem that starts the commport running. 4. When logfileopen is pressed before the commport is started, it works. 5. When logfileopen is pressed after the commport is started, it hangs. 6. setprefix works whether or not the commport is started. 7. portIdentifier.open starts a thread that goes into a native method, RXTXPort.eventLoop, and never returns. 8. java.sun bugs has a bug report, 6741890, that is similar but their workaround doesn't. 9. When it locks up, there is a swing-shell thread that appears to be down in some native libraries, winshellfolder2 10. The awt-eventQ thread is unblocked but in code that says its parked. If you have anymore ideas, I'd really appreciate them. wjr Tod E. Kurt wrote: > This is the exact technique I use to let the user choose which serial > port to use on startup. Here's a method I've got in many of my sketches: > > void choosePort() { > String portlist[] = Serial.list(); > String port = null; > javax.swing.SwingUtilities.invokeLater(new Runnable() { > public void run() { > try { > String port = (String) javax.swing.JOptionPane.showInputDialog( > null, > "Select Serial Port", > "MySuperSketch", > javax.swing.JOptionPane.QUESTION_MESSAGE, > null, portlist, null); > if( port == null ) { > javax.swing.JOptionPane.showMessageDialog(null, "No port > chosen, goodbye"); > System.exit(1); > } > serialPort = port; > } > catch (Exception e) { > e.printStackTrace(); > } > } > } ); > } > > > On May 8, 2009, at 2:08 p, Brian Schlining wrote: > >> Bob's probably right...take look at javax.swing.SwingUtilites for the >> workaround to get your swing stuff invoked on the EventDispatchThread >> (EDT). Some swing-methods do work when called outside of the EDT, but >> just to be safe, do your creation and swing calls on the EDT. It's >> really simple, here's an example of a synchronous call. >> >> // Here's how to run stuff on the EDT from a different thread >> SwingUtilities.invokeAndWait(new Runnable() { >> public void run() { >> JFileChooser fc; // create, setup, show your filechooser >> // Get the result from the filechooser >> } >> }); >> >> To do a asynchronous call use SwingUtilities.invokeLater >> >> >> >I wrote a small swing app to download images from an industrial camera. >> >I used the two way serial sample code as a starting point. The app works >> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >> >then try to change the output directory or log file, the jfilechooser >> >winds up trying to unpark (note, parking is not something I'm really >> >familiar with) and doesn't. >> What is the threading structure of your code? >> >> The various high-function Swing components, such as JFileChooser, are >> notorious for doing Really Bad Stuff when invoked from off the Swing >> thread. >> >> Bob >> -- >> Bob Jacobsen, UC Berkeley >> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >> JacobsenRG >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -- >> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >> Brian Schlining >> bschlining at gmail.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx From m.j.tandy at warwick.ac.uk Wed May 13 16:42:24 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Wed, 13 May 2009 23:42:24 +0100 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A0B40A6.5070204@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> <4A0B40A6.5070204@weru.ksu.edu> Message-ID: <302aa0340905131542i601ec3f1w3b0b5879c23f8eca@mail.gmail.com> Perhaps you could post your program, or an excerpt of it sufficient to demonstrate the problem you're having, for us to have a look at? 2009/5/13 Bill Rust : > Tod's solution misses the point. He is picking and opening the serial > port. That's the step before where my problem occurs. > > To recap: > > 1. I have a simple java swing app. > 2. On the menu bar, there is the standard set, file, etc., of jmenu's. > Under file, there is a jmenuitem, logfileopen, which pops up a > jfilechooser to select a logfile and another jmenuitem, setprefix, which > pops up a jdialog to allow the user to type in a file name prefix for > downloaded images. > 3. There is another jmenuitem that starts the commport running. > 4. When logfileopen is pressed before the commport is started, it works. > 5. When logfileopen is pressed after the commport is started, it hangs. > 6. setprefix works whether or not the commport is started. > 7. portIdentifier.open starts a thread that goes into a native > method, ? ? ? ? ? ? ? ? ? ? ? ? RXTXPort.eventLoop, and never returns. > 8. java.sun bugs has a bug report, 6741890, that is similar but > their ? ? ? ? ? ? ? ? ? workaround doesn't. > 9. When it locks up, there is a swing-shell thread that appears to be > ? ? ? ?down in some native libraries, winshellfolder2 > 10. The awt-eventQ thread is unblocked but in code that says its parked. > > If you have anymore ideas, I'd really appreciate them. > > wjr > > Tod E. Kurt wrote: >> This is the exact technique I use to let the user choose which serial >> port to use on startup. ?Here's a method I've got in many of my sketches: >> >> void choosePort() { >> ? String portlist[] = Serial.list(); >> ? String port = null; >> ? javax.swing.SwingUtilities.invokeLater(new Runnable() { >> ? ? public void run() { >> ? ? ? try { >> ? ? ? ? String port = (String) javax.swing.JOptionPane.showInputDialog( >> null, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Select Serial Port", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "MySuperSketch", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? javax.swing.JOptionPane.QUESTION_MESSAGE, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? null, portlist, null); >> ? ? ? ? if( port == null ) ?{ >> ? ? ? ? ? javax.swing.JOptionPane.showMessageDialog(null, "No port >> chosen, goodbye"); >> ? ? ? ? ? System.exit(1); >> ? ? ? ? } >> ? ? ? ? serialPort = port; >> ? ? ? } >> ? ? ? catch (Exception e) { >> ? ? ? ? e.printStackTrace(); >> ? ? ? } >> ? ? } >> ? } ); >> } >> >> >> On May 8, 2009, at 2:08 p, Brian Schlining wrote: >> >>> Bob's probably right...take look at javax.swing.SwingUtilites for the >>> workaround to get your swing stuff invoked on the EventDispatchThread >>> (EDT). Some swing-methods do work when called outside of the EDT, but >>> just to be safe, do your creation and swing calls on the EDT. It's >>> really simple, here's an example of a synchronous call. >>> >>> // Here's how to run stuff on the EDT from a different thread >>> SwingUtilities.invokeAndWait(new Runnable() { >>> ? ? ? public void run() { >>> ? ? ? ? ? ?JFileChooser fc; // create, setup, show your filechooser >>> ? ? ? ? ? ?// Get the result from the filechooser >>> ? ? ? } >>> }); >>> >>> To do a asynchronous call use SwingUtilities.invokeLater >>> >>> >>> >I wrote a small swing app to download images from an industrial camera. >>> >I used the two way serial sample code as a starting point. The app works >>> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >>> >then try to change the output directory or log file, the jfilechooser >>> >winds up trying to unpark (note, parking is not something I'm really >>> >familiar with) and doesn't. >>> What is the threading structure of your code? >>> >>> The various high-function Swing components, such as JFileChooser, are >>> notorious for doing Really Bad Stuff when invoked from off the Swing >>> thread. >>> >>> Bob >>> -- >>> Bob Jacobsen, UC Berkeley >>> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >>> JacobsenRG >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >>> -- >>> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >>> Brian Schlining >>> bschlining at gmail.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From m.j.tandy at warwick.ac.uk Thu May 14 03:05:36 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Thu, 14 May 2009 10:05:36 +0100 Subject: [Rxtx] swing jfilechooser lockup In-Reply-To: <4A0B40A6.5070204@weru.ksu.edu> References: <4A046E15.6010907@weru.ksu.edu> <8AC15179-8B5A-470C-862C-ED38065C9322@todbot.com> <4A0B40A6.5070204@weru.ksu.edu> Message-ID: <302aa0340905140205p6ceb5a9br24e00a50e9cafa5@mail.gmail.com> Java has a built in deadlock detection utility; run your program from the command line, then (on windows) press Ctrl+Break (On Linux, Ctrl+\ does the trick I'm told). That should produce status information and a stack trace for every running thread, including locks held and locks waited on. Maybe that would contain enough information for you to work out what's locking what? 2009/5/13 Bill Rust : > Tod's solution misses the point. He is picking and opening the serial > port. That's the step before where my problem occurs. > > To recap: > > 1. I have a simple java swing app. > 2. On the menu bar, there is the standard set, file, etc., of jmenu's. > Under file, there is a jmenuitem, logfileopen, which pops up a > jfilechooser to select a logfile and another jmenuitem, setprefix, which > pops up a jdialog to allow the user to type in a file name prefix for > downloaded images. > 3. There is another jmenuitem that starts the commport running. > 4. When logfileopen is pressed before the commport is started, it works. > 5. When logfileopen is pressed after the commport is started, it hangs. > 6. setprefix works whether or not the commport is started. > 7. portIdentifier.open starts a thread that goes into a native > method, ? ? ? ? ? ? ? ? ? ? ? ? RXTXPort.eventLoop, and never returns. > 8. java.sun bugs has a bug report, 6741890, that is similar but > their ? ? ? ? ? ? ? ? ? workaround doesn't. > 9. When it locks up, there is a swing-shell thread that appears to be > ? ? ? ?down in some native libraries, winshellfolder2 > 10. The awt-eventQ thread is unblocked but in code that says its parked. > > If you have anymore ideas, I'd really appreciate them. > > wjr > > Tod E. Kurt wrote: >> This is the exact technique I use to let the user choose which serial >> port to use on startup. ?Here's a method I've got in many of my sketches: >> >> void choosePort() { >> ? String portlist[] = Serial.list(); >> ? String port = null; >> ? javax.swing.SwingUtilities.invokeLater(new Runnable() { >> ? ? public void run() { >> ? ? ? try { >> ? ? ? ? String port = (String) javax.swing.JOptionPane.showInputDialog( >> null, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Select Serial Port", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "MySuperSketch", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? javax.swing.JOptionPane.QUESTION_MESSAGE, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? null, portlist, null); >> ? ? ? ? if( port == null ) ?{ >> ? ? ? ? ? javax.swing.JOptionPane.showMessageDialog(null, "No port >> chosen, goodbye"); >> ? ? ? ? ? System.exit(1); >> ? ? ? ? } >> ? ? ? ? serialPort = port; >> ? ? ? } >> ? ? ? catch (Exception e) { >> ? ? ? ? e.printStackTrace(); >> ? ? ? } >> ? ? } >> ? } ); >> } >> >> >> On May 8, 2009, at 2:08 p, Brian Schlining wrote: >> >>> Bob's probably right...take look at javax.swing.SwingUtilites for the >>> workaround to get your swing stuff invoked on the EventDispatchThread >>> (EDT). Some swing-methods do work when called outside of the EDT, but >>> just to be safe, do your creation and swing calls on the EDT. It's >>> really simple, here's an example of a synchronous call. >>> >>> // Here's how to run stuff on the EDT from a different thread >>> SwingUtilities.invokeAndWait(new Runnable() { >>> ? ? ? public void run() { >>> ? ? ? ? ? ?JFileChooser fc; // create, setup, show your filechooser >>> ? ? ? ? ? ?// Get the result from the filechooser >>> ? ? ? } >>> }); >>> >>> To do a asynchronous call use SwingUtilities.invokeLater >>> >>> >>> >I wrote a small swing app to download images from an industrial camera. >>> >I used the two way serial sample code as a starting point. The app works >>> >fine EXCEPT for a call to jfilechooser. After I open the comm port and >>> >then try to change the output directory or log file, the jfilechooser >>> >winds up trying to unpark (note, parking is not something I'm really >>> >familiar with) and doesn't. >>> What is the threading structure of your code? >>> >>> The various high-function Swing components, such as JFileChooser, are >>> notorious for doing Really Bad Stuff when invoked from off the Swing >>> thread. >>> >>> Bob >>> -- >>> Bob Jacobsen, UC Berkeley >>> jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >>> JacobsenRG >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >>> -- >>> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >>> Brian Schlining >>> bschlining at gmail.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From cowwoc at bbs.darktech.org Fri May 15 07:18:29 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 09:18:29 -0400 Subject: [Rxtx] InputStream timeouts Message-ID: <4A0D6BA5.8020209@bbs.darktech.org> Why does InputStream.read() return -1 on timeout instead of throwing InterruptedIOException which has existed specifically for this purpose since JDK 1.0? Sockets throw SocketTimeoutException which extends InterruptedIOException. I suspect that this logic confuses BufferedInputStream as well as end-users. Can we introduce this change along with the other timeout-related changes? Gili From Steffen.DETTMER at ingenico.com Fri May 15 07:36:19 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 15 May 2009 15:36:19 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0D6BA5.8020209@bbs.darktech.org> References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <20090515133619.GC17036@elberon.bln.de.ingenico.com> * cowwoc wrote on Fri, May 15, 2009 at 09:18 -0400: > Why does InputStream.read() return -1 on timeout shouldn't it block and only avialable() should care about timeouts? That is how I understand `This method blocks until input data is available' from: http://java.sun.com/j2se/1.5.0/docs/api/java/io/InputStream.html#read() public abstract int read() throws IOException Reads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown. A subclass must provide an implementation of this method. Returns: the next byte of data, or -1 if the end of the stream is reached. Throws: IOException - if an I/O error occurs. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Fri May 15 08:22:19 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 15 May 2009 17:22:19 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: >From the javadoc for InputStream: "If no byte is available because the end of the stream has been reached, the value -1 is returned." Since character timeout is not an indication of EOF condition I guess one could argue that 0 should be returned in case of timeout. On the other hand one could also argue that since no data was available (if it timed out) the serial port input stream was at the end of stream (albeit possibly temporarily only). Further the javadoc seems to forbid the return value 0 for Inputstream.read(): " This method blocks until input data is available, the end of the stream is detected, or an exception is thrown." So it can return n >= 1 , -1 or throw an exception. InputStream.read(byte[]) can return 0 but for consistency the options with the other read methods the return value for timeout needs to be -1 or an exception. It goes against my grain to think that I get an exception when I've set up a timeout and I am thus expecting a timeout to happen sometimes. So it is not an exceptional case but expected situation in which case a special return value is philosophically speaking more appropriate. So I'm against changing this behavior. I expect a lot of code depend on the -1 or at least on not getting an exception when a timeout occurs. In any case if an exception were to be thrown it should *not* be InterruptedIOException. >From the javadoc for InterruptedIOException: "An InterruptedIOException is thrown to indicate that an input or output transfer has been terminated because the thread performing it was interrupted. The field bytesTransferred indicates how many bytes were successfully transferred before the interruption occurred" I do not think this matches the case for serial port receive character timeout. I read the javadoc above so that I get this exception when the thread in my code that is performing a read or write operation gets interrupted by Thread.interrupt(). And this is used to handle exactly that case: being able to gracefully and cleanly interrupt threads. my 2 snt worth br Kusti > From: cowwoc > Date: Fri, 15 May 2009 16:18:29 +0300 > To: rxtx > Conversation: [Rxtx] InputStream timeouts > Subject: [Rxtx] InputStream timeouts > > > > Why does InputStream.read() return -1 on timeout instead of > throwing InterruptedIOException which has existed specifically for this > purpose since JDK 1.0? Sockets throw SocketTimeoutException which > extends InterruptedIOException. I suspect that this logic confuses > BufferedInputStream as well as end-users. Can we introduce this change > along with the other timeout-related changes? > > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From cowwoc at bbs.darktech.org Fri May 15 08:35:27 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 10:35:27 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <4A0D7DAF.5030705@bbs.darktech.org> I disagree with your interpretation. Read SocketTimeoutException to see what I mean. InterruptedIOException means the operation was interrupted, not necessarily by way of Thread.interrupt(). Returning 0 in case of timeout sounds wrong to me because it is a legal byte value that could have been read. Returning -1 also sounds wrong to me because this isn't strictly the end of stream. BufferedInputStream and others assume that once you reach the end of stream you will never see more data, ever. As far as I know, the core APIs are written in terms of throwing InterruptedIOException for timeouts. Gili Kustaa Nyholm wrote: > >>From the javadoc for InputStream: > > "If no byte is available because the end of the stream has been reached, the > value -1 is returned." > > > Since character timeout is not an indication of EOF condition I guess one > could argue that 0 should be returned in case of timeout. On the other hand > one could also argue that since no data was available (if it timed out) the > serial port input stream was at the end of stream (albeit possibly > temporarily only). Further the javadoc seems to forbid the return value 0 > for Inputstream.read(): > > " This method blocks until input data is available, the end of the stream is > detected, or an exception is thrown." > > So it can return n >= 1 , -1 or throw an exception. InputStream.read(byte[]) > can return 0 but for consistency the options with the other read methods the > return value for timeout needs to be -1 or an exception. > > It goes against my grain to think that I get an exception when I've set up a > timeout and I am thus expecting a timeout to happen sometimes. So it is not > an exceptional case but expected situation in which case a special return > value is philosophically speaking more appropriate. > > So I'm against changing this behavior. I expect a lot of code depend on the > -1 or at least on not getting an exception when a timeout occurs. > > In any case if an exception were to be thrown it should *not* be > InterruptedIOException. > >>From the javadoc for InterruptedIOException: > > > "An InterruptedIOException is thrown to indicate that an input or output > transfer has been terminated because the thread performing it was > interrupted. The field bytesTransferred indicates how many bytes were > successfully transferred before the interruption occurred" > > I do not think this matches the case for serial port receive character > timeout. I read the javadoc above so that I get this exception when the > thread in my code that is performing a read or write operation gets > interrupted by Thread.interrupt(). And this is used to handle exactly that > case: being able to gracefully and cleanly interrupt threads. > > > > my 2 snt worth br Kusti > > > > >> From: cowwoc >> Date: Fri, 15 May 2009 16:18:29 +0300 >> To: rxtx >> Conversation: [Rxtx] InputStream timeouts >> Subject: [Rxtx] InputStream timeouts >> >> >> >> Why does InputStream.read() return -1 on timeout instead of >> throwing InterruptedIOException which has existed specifically for this >> purpose since JDK 1.0? Sockets throw SocketTimeoutException which >> extends InterruptedIOException. I suspect that this logic confuses >> BufferedInputStream as well as end-users. Can we introduce this change >> along with the other timeout-related changes? >> >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From m.j.tandy at warwick.ac.uk Fri May 15 09:17:36 2009 From: m.j.tandy at warwick.ac.uk (Michael Tandy) Date: Fri, 15 May 2009 16:17:36 +0100 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <302aa0340905150817o39812d7y1b896004a2dcc2ab@mail.gmail.com> > I disagree with your interpretation. Read SocketTimeoutException to see > what I mean. InterruptedIOException means the operation was interrupted, > not necessarily by way of Thread.interrupt(). Strangely enough, the javadoc for InterruptedIOException says: "An InterruptedIOException is thrown to indicate that an input or output transfer has been terminated because the thread performing it was interrupted."[1] But the subclass SocketTimeoutException is used differently - here's an example from sun.net.httpserver.request: /** * block() only called when available==0 and buf is empty */ private synchronized void block () throws IOException { long currtime = server.getTime(); long maxtime = currtime + readTimeout; while (currtime < maxtime) { if (selector.select (readTimeout) == 1) { selector.selectedKeys().clear(); available (); return; } currtime = server.getTime(); } throw new SocketTimeoutException ("no data received"); } So it seems that SocketTimeoutExceptions get thrown not upon thread interruptions, but a certain time after a blocking read is started. [1] http://java.sun.com/javase/6/docs/api/java/io/InterruptedIOException.html From cowwoc at bbs.darktech.org Fri May 15 11:06:53 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 15 May 2009 13:06:53 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0DA0F4.9050203@bbs.darktech.org> References: <4A0DA0F4.9050203@bbs.darktech.org> Message-ID: <4A0DA12D.2050303@bbs.darktech.org> Forgot to CC the list. Gili cowwoc wrote: > > "Thread was interrupted" does not necessarily mean > Thread.interrupt(). It just means that the operation (run by the thread) > was interrupted. If you read the beginning sentence for > InterruptedIOException it reads "Signals that an I/O operation has been > interrupted". This says nothing about the thread itself. Michael's > subsequent post about SocketTimeoutException reinforces that point. > > By the way, I think that in general you need to interpret the > Javadoc for core classes in a broader sense than it seems. Older Javadoc > (from version 1.0) used to mention implementation details that were not > necessarily important and limited the applicability of the classes. > Newer documentation tends to go out of its way to avoid mentioning such > implementation detail and I believe that's a good thing. When > InterruptedIOException was written, Thread.interrupt() was probably the > only way to interrupt I/O operations. Nowadays there are others. Sun has > generalized its meaning over time as evident by SocketTimeoutException. > At least, that's my interpretation :) > > Gili > > Kustaa Nyholm wrote: >>> I disagree with your interpretation. Read >>> SocketTimeoutException to >>> see >>> what I mean. InterruptedIOException means the operation was interrupted, >>> not necessarily by way of Thread.interrupt(). >> >> Well SocketTimeoutException javadoc only says, very briefly: >> >> "Signals that a timeout has occurred on a socket read or accept." >> >> So that is not too helpful. But since it is derived from >> InterruptedIOException my interpretation it that they have an 'is-a' >> relationship and InterruptedIOException needs to honor the contract of >> InterruptedIOException which says: >> >> "...because the thread performing it was interrupted." >> >> To me this very specifically talks about interrupting threads with >> Thread.interrupt() >> >> >>> Returning 0 in case of timeout sounds wrong to me because it >>> is a >>> legal >>> byte value that could have been read. >> Agreed, that's what I tried to say. 0 is a legal byte value for read() to >> return so that cannot be used. For read read(byte[]) which returns the >> number of bytes read 0 could be used but there again 0 can be returned >> if 0 >> byte[] size is 0. So there again 0 is not a good option. >> >>> Returning -1 also sounds wrong to >>> me because this isn't strictly the end of stream. >> Like I said, it isn't strictly the end of stream. But also does not >> forbid treating it as (temporary) end of stream. >> >>> BufferedInputStream >>> and others assume that once you reach the end of stream you will never >>> see more data, ever. >> Can you provide a reference for that. >> >>> As far as I know, the core APIs are written in >>> terms of throwing InterruptedIOException for timeouts. >> Would also like to see something to support that. >> >> >> The behavior of throwing an exception on timeout is also a little bit >> problematic, consider: >> >> byte buf[1000]; >> int n=ins.read(buf); >> // do something with the n bytes received >> >> What happens if a timeout occurs before we have received 1000 bytes? >> >> If an exception is thrown then the user of the read() needs to handle >> the bytes received in two places or else those last <1000 bytes are lost. >> A better solution would be to return the bytes received so far and throw >> the exception on the next call (if any). But the main point is that >> neither of these case obviously correct and neither is specified in the >> javadocs. Where as a lot of code that just handles the return value >> of read(byte[]) correctly works without any further ado. >> >> >> >> The main thing is that I think we should not break existing applications, >> which I expect are not handling InterruptedIOException but many of >> which may >> depend on getting back -1 in case of timeouts. >> >> It has been a while since I used the javax.javacomm but I seem to recall >> that it returned -1 and I think this is the defining standard. >> >> I expect most rxtx users are more interested in compatibility and >> stability >> than semantic niceties and improving the API. >> >> br Kusti >> >> >> > From johnny.luong at trustcommerce.com Fri May 15 13:16:15 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Fri, 15 May 2009 12:16:15 -0700 Subject: [Rxtx] InputStream timeouts In-Reply-To: <4A0DA12D.2050303@bbs.darktech.org> References: <4A0DA0F4.9050203@bbs.darktech.org> <4A0DA12D.2050303@bbs.darktech.org> Message-ID: <4A0DBF7F.50808@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 cowwoc wrote: | Forgot to CC the list. | | Gili | | cowwoc wrote: |> "Thread was interrupted" does not necessarily mean |> Thread.interrupt(). It just means that the operation (run by the thread) |> was interrupted. If you read the beginning sentence for |> InterruptedIOException it reads "Signals that an I/O operation has been |> interrupted". This says nothing about the thread itself. Michael's |> subsequent post about SocketTimeoutException reinforces that point. |> |> By the way, I think that in general you need to interpret the |> Javadoc for core classes in a broader sense than it seems. Older Javadoc |> (from version 1.0) used to mention implementation details that were not |> necessarily important and limited the applicability of the classes. |> Newer documentation tends to go out of its way to avoid mentioning such |> implementation detail and I believe that's a good thing. When |> InterruptedIOException was written, Thread.interrupt() was probably the |> only way to interrupt I/O operations. Nowadays there are others. Sun has |> generalized its meaning over time as evident by SocketTimeoutException. |> At least, that's my interpretation :) |> |> Gili |> |> Kustaa Nyholm wrote: |>>> I disagree with your interpretation. Read |>>> SocketTimeoutException to |>>> see |>>> what I mean. InterruptedIOException means the operation was interrupted, |>>> not necessarily by way of Thread.interrupt(). |>> Well SocketTimeoutException javadoc only says, very briefly: |>> |>> "Signals that a timeout has occurred on a socket read or accept." |>> |>> So that is not too helpful. But since it is derived from |>> InterruptedIOException my interpretation it that they have an 'is-a' |>> relationship and InterruptedIOException needs to honor the contract of |>> InterruptedIOException which says: |>> |>> "...because the thread performing it was interrupted." |>> |>> To me this very specifically talks about interrupting threads with |>> Thread.interrupt() |>> |>> |>>> Returning 0 in case of timeout sounds wrong to me because it |>>> is a |>>> legal |>>> byte value that could have been read. |>> Agreed, that's what I tried to say. 0 is a legal byte value for read() to |>> return so that cannot be used. For read read(byte[]) which returns the |>> number of bytes read 0 could be used but there again 0 can be returned |>> if 0 |>> byte[] size is 0. So there again 0 is not a good option. |>> |>>> Returning -1 also sounds wrong to |>>> me because this isn't strictly the end of stream. |>> Like I said, it isn't strictly the end of stream. But also does not |>> forbid treating it as (temporary) end of stream. |>> |>>> BufferedInputStream |>>> and others assume that once you reach the end of stream you will never |>>> see more data, ever. |>> Can you provide a reference for that. |>> |>>> As far as I know, the core APIs are written in |>>> terms of throwing InterruptedIOException for timeouts. |>> Would also like to see something to support that. |>> |>> |>> The behavior of throwing an exception on timeout is also a little bit |>> problematic, consider: |>> |>> byte buf[1000]; |>> int n=ins.read(buf); |>> // do something with the n bytes received |>> |>> What happens if a timeout occurs before we have received 1000 bytes? |>> |>> If an exception is thrown then the user of the read() needs to handle |>> the bytes received in two places or else those last <1000 bytes are lost. |>> A better solution would be to return the bytes received so far and throw |>> the exception on the next call (if any). But the main point is that |>> neither of these case obviously correct and neither is specified in the |>> javadocs. Where as a lot of code that just handles the return value |>> of read(byte[]) correctly works without any further ado. |>> |>> |>> |>> The main thing is that I think we should not break existing applications, |>> which I expect are not handling InterruptedIOException but many of |>> which may |>> depend on getting back -1 in case of timeouts. |>> |>> It has been a while since I used the javax.javacomm but I seem to recall |>> that it returned -1 and I think this is the defining standard. |>> |>> I expect most rxtx users are more interested in compatibility and |>> stability |>> than semantic niceties and improving the API. |>> |>> br Kusti |>> |>> |>> | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi, Maybe a better approach (improving the API) would be to consider implementing a NIO interface atop the underlying serial communication... ~ if someone desires the existing behavior, then they use a facade that lies atop of the NIO and provide the same quirks associated with it. As I see it, the implementation overrides the general contract of the InputStream to provide for the timeout functionality and it would be somewhat troublesome to expect a user of that API to catch subclasses of IOException. Best, Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoNv38ACgkQnQTBLXttTeWZ+wCeO4CTrI5l+vLPrjHl8fBj7FOL Ft8AnjQ7bXnvMhOlwZdK5CYAuoQeQ9u0 =QAax -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon May 18 03:49:50 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 11:49:50 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <4A0D6BA5.8020209@bbs.darktech.org> Message-ID: <20090518094950.GG17036@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, May 15, 2009 at 17:22 +0300: > >From the javadoc for InputStream: > > Since character timeout is not an indication of EOF condition I > guess one could argue that 0 should be returned in case of > timeout. A blocking operation logically has no timeout. It is blocking. Forever, until EOF or an error. This IMHO renders usage of read() useless and read(byte[]) must be used (or no InputStream). > On the other hand one could also argue that since no data was > available (if it timed out) IMHO, read() must not time out. What would happen with a small simple console app that is relying that InputStream is implemented as required by specification? It cannot tell `no byte was received but this is not an error, please call me again' - and why should it? I think, if this is not suited, i.e. if the application may want a byte but also may not want a byte, no blocking function must be invoked, but a select must be called instead or, if no select-style function is avialable, polling must be used. This is the InputStream way (block or poll). For streams the `may or may not want a byte' may sound unlikely, but in practice this is what happens, for instance, if there is some CANCEL button in a GUI or so. Closing the stream often also is no option because it cannot be reopend but it might be needed again later. In classic unix apps often signals were used (read(2) can return EINTR), but in Java this isn't possible AFAIK. EINTR IMHO has not much relation to InterruptedIOException and I think InterruptedIOException cannot be `enforced' without doing harm. > It goes against my grain to think that I get an exception when > I've set up a timeout yeah, I thought the same and when I hit this InputStream the first time I though: ohh, a bug. Or a bunch of :-) As specified, InputStream has no timeout. If you set a timeout, then somewhere else (e.g. a sub class). In this case, the sub class should also offer a way to wait for this timeout (e.g. a select style function). In practice, this makes not much sense, leaving the options not to use it at all (but what else then?) or to violate the specification. Unfortunately it seems that subclasses add setTimeout but no select() or tryRead() or simply a available()-style with a timeout parameter. Then applications would simply use this subclasses. In practice, then it does not help that they derive InputStream at all, so personally I think they should not derive from it but instead define something with a meaning :-) But I think in practice, for read(byte[]) returning 0 (e.g. in case of [intercharacter] timeout) for many people seems straightforward - so this is probably what most people will expect. (an interesting question is how those bugs happend to the Java guys, because those topics are well known since ages and solved, for instance, in the BSD socket API, but probably they didn't know it. It took years but now it seems they understood and tried it again by some NIO which is more in the `usual way'. Next version might be usable - I wouldn't be surprised if this one then is BSD socket API alike :-) SCNR). So in practice I think: - don't use read() but read(byte[]) or read(byte[], int, int) - handle `0 bytes read' situation - polling avialable() in practice may often not be suited because avialable() has no timeout parameter and if response time is important, small polling intervals would be needed which generate load - try to avoid using InputStream (from applications) directly because it sucks and it is /not/ generic (implementations may interpret it differently because it MUST be interpreted because the specification makes not much sense in many cases) - IOException and InterruptedIOException are for I/O error situations. Additionally I think, InterruptedIOException.bytesTransferred cannot be reliable because there are cases where the OS cannot surely know this and thus cannot tell it the JVM also, peer may have not received them even if they were sent As far as I know this is exactly what rxtx is doing. When having many clients this require many threads and might be less performant, so best is not to have one thousand serial ports :-) Returning 0 here IMHO also is the only option that does not `directly' violate the spec. It tells `there is an attempt to read at least one byte.' so someone could argue that the dear computer `attempted but found no time to do so' :-) > So I'm against changing this behavior. I expect a lot of code > depend on the -1 or at least on not getting an exception when a > timeout occurs. Yes, I agree, -1 means End of file (or closed by peer) and exceptions are for errors. If exceptions should be added I think it could be made configurable. For instance by some Rs232InputStream.enableException(IOException e), store this exception and later if (e != null) throw e.clone() or so. > I do not think this matches the case for serial port receive character > timeout. I read the javadoc above so that I get this exception when the > thread in my code that is performing a read or write operation gets > interrupted by Thread.interrupt(). And this is used to handle exactly that > case: being able to gracefully and cleanly interrupt threads. (well, I think Thread.interrupt() also is a big topic on its own and I'm afraid there is no really reliable mechanism for `cleanly interrupt threads' and maybe even that logically threads cannot be interrupted cleanly at all) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From rxtx at qbang.org Mon May 18 05:17:08 2009 From: rxtx at qbang.org (VIAGRA ® Official Site) Date: Mon, 18 May 2009 05:17:08 -0600 Subject: [Rxtx] DISCOUNT ID42992 75% 0FF on Pfizer ! Message-ID: <200905181117.n4IBH8ku024296@rxtx.qbang.org> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/4c172d08/attachment-0009.html From Kustaa.Nyholm at planmeca.com Mon May 18 07:20:40 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 18 May 2009 16:20:40 +0300 Subject: [Rxtx] InputStream timeouts Message-ID: Oops, sorry sent this to Steffen directly instead of mailing list. So here for the list: > A blocking operation logically has no timeout. It is blocking. > Forever, until EOF or an error. This IMHO renders usage of read() > useless and read(byte[]) must be used (or no InputStream). This is true, however read(byte[]) too is blocking so logically that (allowing it to return with value 0 in case of timeout) is no better (or worse) than read(). According to InputsStream javadoc only when byte[].length is 0 is read(byte[]) non blocking and can return 0. But to be clear: I'm in favor of returning 0 in case of timeouts for read(byte[]) and -1 for read(). > >> On the other hand one could also argue that since no data was >> available (if it timed out) > > IMHO, read() must not time out. IMHO read() should behave consistently with respect to the other read(...) methods. If we allow them to timeout, we should also allow read() to timeout. And in that case we need a return value that separates that case from normal return value (0-255), so -1 seems like a good candidate. > What would happen with a small > simple console app that is relying that InputStream is > implemented as required by specification? It cannot tell `no byte > was received but this is not an error, please call me again' > - and why should it? I think that the simple console app would be just fine, because timeouts are disabled by default so the simple applications are not affected. > > In practice, this makes not much sense, leaving the options not > to use it at all (but what else then?) or to violate the > specification. The javadoc for CommPort.getInputStream() spells out the rules for timeouts: http://java.sun.com/products/javacomm/reference/api/javax/comm/CommPort.html #getInputStream() So, IMO, while it is interesting to discuss these things the javacomm specs is quite clear about blocking behavior and although there is some conflict between how (file) inputstream behaves and Commport inputstreams behave, I think rxtx should adhere to the javacomm spec. > But I think in practice, for read(byte[]) returning 0 (e.g. in > case of [intercharacter] timeout) for many people > seems straightforward - so this is probably what most people will > expect. Agreed, I'm 100% sure there are lots of people out there that use timeouts and depend on the current behavior. Changing this would not help them but infuriate them. > > (well, I think Thread.interrupt() also is a big topic on its own > and I'm afraid there is no really reliable mechanism for > `cleanly interrupt threads' and maybe even that logically > threads cannot be interrupted cleanly at all) Would be interesting to discuss that too but that is beyond the topic of this thread. However I still believe that the InterruptedIOException was introduced so that blocking IO calls could gracefully 'return' if the calling thread was interrupted. Weather this is reliable or clean or graceful could be discussed but to me it seem reasonable. If you have a thread that is blocking on some I/O we need a mechanism that allows stopping that thread in a controlled manner and InterruptedIOException seems to provide this. cheers Kusti From Steffen.DETTMER at ingenico.com Mon May 18 09:18:37 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 17:18:37 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: Message-ID: <20090518151837.GS17036@elberon.bln.de.ingenico.com> [OT] * Kustaa Nyholm wrote on Mon, May 18, 2009 at 16:20 +0300: > > A blocking operation logically has no timeout. It is blocking. > > Forever, until EOF or an error. This IMHO renders usage of read() > > useless and read(byte[]) must be used (or no InputStream). > This is true, however read(byte[]) too is blocking so logically that > (allowing it to return with value 0 in case of timeout) is no better > (or worse) than read(). According to InputsStream javadoc only when > byte[].length is 0 is read(byte[]) non blocking and can return 0. I think the essential difference is that for read(byte[]) returning 0 is somewhat clear, but for read() 0 is a valid byte and thus it would be a horrible mess to also use it for timeouts :) > >> On the other hand one could also argue that since no data was > >> available (if it timed out) > > > > IMHO, read() must not time out. > > IMHO read() should behave consistently with respect to the > other read(...) methods. If we allow them to timeout, we should > also allow read() to timeout. And in that case we need a return > value that separates that case from normal return value (0-255), > so -1 seems like a good candidate. Well, but then this is not consistently to EOF handling... (and if read() cannot be consistent, maybe not using it at all is an option?) > > What would happen with a small simple console app that is > > relying that InputStream is implemented as required by > > specification? It cannot tell `no byte was received but this > > is not an error, please call me again' - and why should it? > I think that the simple console app would be just fine, because > timeouts are disabled by default so the simple applications are > not affected. Not setting timeouts IMHO does not mean no timeouts will be applied but that some default timeout is used instead, which could be infinite or some OS value, which in turn may be configurable (like the TCP wait timeouts). > > In practice, this makes not much sense, leaving the options not > > to use it at all (but what else then?) or to violate the > > specification. > > The javadoc for CommPort.getInputStream() spells out the rules for > timeouts: > > http://java.sun.com/products/javacomm/reference/api/javax/comm/CommPort.html > #getInputStream() > So, IMO, while it is interesting to discuss these things > the javacomm specs is quite clear about blocking behavior > and although there is some conflict between how (file) inputstream > behaves and Commport inputstreams behave, I think rxtx should > adhere to the javacomm spec. I think first this does not clearly state what happens a read caller when a timeout occures and second IMHO it does violate the InputStream specification contract (API/javadoc). Formally speaking, it is a bug :-) Also those `advisory methods' in a formal interface are bad, I think. But another topic and discussed already several times :) Yes, in the end it seems the clear correct possiblity (no timeouts) makes no sense, so something pragmatic is needed :-) > > But I think in practice, for read(byte[]) returning 0 (e.g. in > > case of [intercharacter] timeout) for many people > > seems straightforward - so this is probably what most people will > > expect. > Agreed, I'm 100% sure there are lots of people out there that > use timeouts and depend on the current behavior. Changing this > would not help them but infuriate them. yeah, and when shifting to another type of InputStream suddenly they may break, rendering that interface a bit useless, but this is all we have... Correct IMHO would be that the compiler is able to check whether an interface supports timeouts or not (i.e. all methods exist and work as specified or a different interface must be used. Lets say we would have InputStream and InputStreamTimeout or whatever, there would be so many possibilities, but most with own disadvantages). Well, I wonder why they did not even add a timeout parameter to available() and why they forgot about write timeouts completely (also there is no counterpart to available()). Anyway. > > (well, I think Thread.interrupt() also is a big topic on its own > > and I'm afraid there is no really reliable mechanism for > > `cleanly interrupt threads' and maybe even that logically > > threads cannot be interrupted cleanly at all) > Would be interesting to discuss that too but that is beyond the > topic of this thread. However I still believe that the > InterruptedIOException was introduced so that blocking > IO calls could gracefully 'return' if the calling thread > was interrupted. Yes, maybe they forgot it in first place, then found that read can throw IOExceptions only and thus invented InterruptedIOException for InterruptedException-alike cases? but anyway. > Weather this is reliable or clean or graceful could be > discussed but to me it seem reasonable. (With not reliable I mean, when for instance you wanted to write 10 byte and you get this exception telling 5 byte have been written, you cannot be sure what this means. Maybe the 6th byte is in a fifo or whatever. I think best is to avoid the need to handle this). > If you have a thread that is blocking on some I/O we need a > mechanism that allows stopping that thread in a controlled > manner and InterruptedIOException seems to provide this. I think also this is not reliable, because even if the JVM knows a thread is supposed to be `killed', I see at least two issues: first is that native code may be active and cannot be forced to return and second it could be that the thread would need to perform clean up tasks, and since Java does not support RAII (destructors cannot clean), at least you get in trouble when exceptions happening during this cleanup (i.e. exceptions after the thread stops). This in turn IMHO is likely to happen because a well-known situation to interrupt such a thread might be after some error, and after errors exceptions I think happen more often (because less well tested and others). Let's say the thread uses an InputStream (owned by someone else) and now discards it by calling it's close (which should be a delete - because what is an input stream which is closed? Obviously it is not an input stream anymore :-)). Now you might have a special InputStream requiring special things (it might be a protocol requiring some final quit message to be sent, it might need not to close it if used by someone else, too, additional actions may be needed). Logically this could be implemented (turing complete language :-)), but in practice it might not be possible, simply because too complex (to do it right in all circumstances). oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Mon May 18 10:02:39 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 18 May 2009 19:02:39 +0300 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: > Not setting timeouts IMHO does not mean no timeouts will be > applied but that some default timeout is used instead, which > could be infinite or some OS value, which in turn may be > configurable (like the TCP wait timeouts). > The javadoc says: "By default, receive timeout is not enabled." and "By default, receive threshold is not enabled." thus (from getInputStream javadoc): "block until any data is available" which is consistent InputStream contract. > I think first this does not clearly state what happens a read > caller when a timeout occures That is true. > and second IMHO it does violate the > InputStream specification contract (API/javadoc). Formally > speaking, it is a bug :-) Agreed, but I think given the advantages you get by using InputStream (as means of reading the serial port as opposed to coming up with some totally new Stream concept) I think this was reasonable compromise and bending of the rules. > yeah, and when shifting to another type of InputStream suddenly > they may break, rendering that interface a bit useless, but this > is all we have... Exactly. > (With not reliable I mean, when for instance you wanted to write > 10 byte and you get this exception telling 5 byte have been > written, you cannot be sure what this means. Maybe the 6th byte > is in a fifo or whatever. I think best is to avoid the need to > handle this). I think all we can assume is that at least 5 bytes have been written into the native driver, weather they are in the fifo or whatever we cannot know. But as you wrote, best avoid depending on this behaviour. > I think also this is not reliable, because even if the JVM knows > a thread is supposed to be `killed', I see at least two issues: > first is that native code may be active and cannot be forced to > return Yes, but this is sort of implementation detail, not an API or Java design issue. The JVM and system class implementations should guarantee this (I bet they don't, consistently, for all platforms and OSes). > and second it could be that the thread would need to > perform clean up tasks, and since Java does not support RAII > (destructors cannot clean), at least you get in trouble when > exceptions happening during this cleanup (i.e. exceptions after > the thread stops). I sort of see what you mean, but still I do not see how this could happen if the cleanup catches exceptions properly. But then I've not studied this in detail. > This in turn IMHO is likely to happen because > a well-known situation to interrupt such a thread might be after > some error, and after errors exceptions I think happen more often > (because less well tested and others). > > Let's say the thread uses an InputStream (owned by someone else) > and now discards it by calling it's close (which should be a > delete - because what is an input stream which is closed? > Obviously it is not an input stream anymore :-)). > Now you might have a special InputStream requiring special things > (it might be a protocol requiring some final quit message to be > sent, it might need not to close it if used by someone else, > too, additional actions may be needed). > Logically this could be implemented (turing complete language :-)), > but in practice it might not be possible, simply because too > complex (to do it right in all circumstances). Ok, I think I understand what you mean: you are saying that what mention aboce "if the cleanup catches exceptions properly" maybe be and often is too difficult/complex to implement and test properly? Yeah, seen that, been there, fallen for it... cheers Kusti From Steffen.DETTMER at ingenico.com Mon May 18 10:39:26 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 18 May 2009 18:39:26 +0200 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: <20090518163925.GV17036@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Mon, May 18, 2009 at 19:02 +0300: > > Not setting timeouts IMHO does not mean no timeouts will be > > applied but that some default timeout is used instead, which > > could be infinite or some OS value, which in turn may be > > configurable (like the TCP wait timeouts). > > > The javadoc says: > "By default, receive timeout is not enabled." > and > "By default, receive threshold is not enabled." mmm... but they are optional, so what if a driver does not support timeouts but underlaying comm interface does? anyway, *I* would not rely (but loop) but maybe this is not needed. > > and second IMHO it does violate the > > InputStream specification contract (API/javadoc). Formally > > speaking, it is a bug :-) > Agreed, but I think given the advantages you get by using > InputStream (as means of reading the serial port as opposed > to coming up with some totally new Stream concept) I think > this was reasonable compromise and bending of the rules. I don't like InputStream at all. I think it is not an abstraction to remove and later re-add (hack in) needing things. I dislike that noone knows whether it streams bytes or chars or unicode or whatever. Also, I'm used birectional things (`all things are files') for communications, I think it is simpler. So InputStream IMHO is oversimplified. Maybe it was inspired by unix line discipline (but you can select it :-)). Who knows. Anyway. > > I think also this is not reliable, because even if the JVM knows > > a thread is supposed to be `killed', I see at least two issues: > > first is that native code may be active and cannot be forced to > > return > Yes, but this is sort of implementation detail, not an API or > Java design issue. The JVM and system class implementations should > guarantee this (I bet they don't, consistently, for all platforms > and OSes). I think when no reasonable implementation is possible, probably the design is not good. If there is no reasonable way to shutdown (kill) a thread (which is the case IMHO), it makes not much sense to design it. Instead, some mechanism would be needed. I guess the InterruptedException in fact is such a kind of mechanism. I'm not sure but I think Java itself disencourages to use it. > > and second it could be that the thread would need to > > perform clean up tasks, and since Java does not support RAII > > (destructors cannot clean), at least you get in trouble when > > exceptions happening during this cleanup (i.e. exceptions after > > the thread stops). > I sort of see what you mean, but still I do not see how this > could happen if the cleanup catches exceptions properly. But > then I've not studied this in detail. > Ok, I think I understand what you mean: you are saying that > what mention aboce "if the cleanup catches exceptions properly" > maybe be and often is too difficult/complex to implement and > test properly? Yes, since it should work for any implementation, it should work for InputStreams that call abitrary complex read operations. I have applications where the read leads to some CORBA calls to a remote C++ application which also has its complexity. Now in some finally {} exceptions can occure, for instance during member destruction (closing). For example, if you have a facade like implementation with: { old = setMyLogLevel(off); for (i=0; i Yeah, seen that, been there, fallen for it... (welcome in the club :-)) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bill7007 at gmail.com Mon May 18 11:08:45 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 18 May 2009 13:08:45 -0400 Subject: [Rxtx] InputStream timeouts In-Reply-To: <20090518151837.GS17036@elberon.bln.de.ingenico.com> References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: I can add this thought, I think the timeout is part of a protocol, which should sit above RXTX. The main feature needed in RXTX to support a protocol using timeouts is a way to interrupt it into a known state, like a reset() function. The function should cause an exception to any associated thread that was waiting on IO, maybe a unique exception due to reset() call. An IO (as opposed to Interrupted) exception may be better since the reset() has to leave a known state which may affect IO in progress. I helped work a similar situation in a CAN bus protocol. In the protocol, a send would be followed by a wait for receive. A timeout thread was enabled which caused an "alarm" event to any registered handlers upon timeout. A receive canceled the timeout alarm. The timing and thread coordination is tricky but that is all left to the protocol code. The protocols timeout event handler reset the CAN controller to get it into a known state for a retry. The reset caused an IO exception to the waiting read thread which could check that a timeout had caused it. So, if timeout is considered part of a higher level protocol class, read and write don't need special interface features as long as there is a way for a waiting state in native code to be forced to exit in a reliable, detectable, manner. +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090518/c9b25045/attachment-0008.html From johnny.luong at trustcommerce.com Mon May 18 11:49:53 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 18 May 2009 10:49:53 -0700 Subject: [Rxtx] InputStream timeouts In-Reply-To: References: <20090518151837.GS17036@elberon.bln.de.ingenico.com> Message-ID: <4A119FC1.3090700@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Johnson wrote: | I can add this thought, I think the timeout is part of a protocol, which | should sit above RXTX. The main feature needed in RXTX to support a protocol | using timeouts is a way to interrupt it into a known state, like a reset() | function. The function should cause an exception to any associated thread | that was waiting on IO, maybe a unique exception due to reset() call. An IO | (as opposed to Interrupted) exception may be better since the reset() has to | leave a known state which may affect IO in progress. | | I helped work a similar situation in a CAN bus protocol. In the protocol, a | send would be followed by a wait for receive. A timeout thread was enabled | which caused an "alarm" event to any registered handlers upon timeout. A | receive canceled the timeout alarm. The timing and thread coordination is | tricky but that is all left to the protocol code. The protocols timeout | event handler reset the CAN controller to get it into a known state for a | retry. The reset caused an IO exception to the waiting read thread which | could check that a timeout had caused it. | | So, if timeout is considered part of a higher level protocol class, read and | write don't need special interface features as long as there is a way for a | waiting state in native code to be forced to exit in a reliable, detectable, | manner. | | +BillJ | | | | ------------------------------------------------------------------------ | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx Hi Bill, This is all conjecture and probably a lot of work in practice, so its just a train of thought at this point (via NIO)... Supposer SerialPort were to implement a method that returned "SerialPortChannel" which worked along similar lines as a SocketChannel. ~ Then you could in practice, have a Selector object that did the timeout you described above (via a register method)... your read and write methods could block or not block and it would be a lot easier to drive multiple serial ports than what you have today. - -Johnny -----BEGIN PGP SIGNATURE----- Version: Gnu